Merevlemezek, vezérlők

Lenne egy mdraid raid1 2 diskből. Erre tettem egy LVM-et. Az egyik disk-et cserélném, mert tönkrement. De sehogy nem tudom feltenni a grub-ot az új disk-re.
Már szét google-ztam az agyam, de nem lettem okosabb.
Ha a /dev/sdb-re akarom tenni a grub-ot, akkor közli, hogy van raid és tegyem al LVM root eszközre, és/vagy tegyem bele a device.map-ba, de ha beleteszem, akkor meg nem érti mi az.

Valaki belefutott hasonlóba, talált megoldást?

Vettem egy HD103SJ-t márciusban, azóta szép lassan 44-re nőtt a CRC hibák száma. Write error is volt egy ideig, áprilisig felment 26-ra, azóta nem mozdult. Minden egyéb érték tökéletes. HD sentinel szerint minden rendben.

199,Ultra ATA CRC Error Count,0,100,100,OK (Mindig rendben),44,0,Engedélyezve
200,Write Error Rate,0,100,100,OK (Mindig rendben),26,0,Engedélyezve

Néha azt a félelmetes jelenséget produkálja, hogy nem látom rajta a partíciókat Windowsban, eltűnnek a meghajtó betűjelek. Újraindulás után megint jó. Hibás szektorok nincsenek, összehasonlítottam a backuppal. Azt vettem észre, hogy menet közben nem növekszik, csak valamikor kikapcsolás után és bekapcsolás előtt. Feltételezem, hogy ha épp boot közben van a hiba, akkor onnan kezdve láthatatlan lesz újraindításig. A Windows szerint ilyenkor olvashatatlan a lemez, nem lehet újraolvasni a köteteket, tehát talán már a BIOS szintjén válik elérhetetlenné.

Sok helyen írják, hogy hibás kábel okozhatja. Egyszer megmozgattam, később cseréltem kábelt, és másik portba dugtam. Rémlik, hogy a write errorok az első mozgatás után szűntek meg. Viszont CRC hiba még azóta is van. Mi folyik itt?

UPDATE: Megnéztem a SMART error logot, amit a HD sentinelben nem találtam, ezért jutott csak később eszembe. SMART READ DATA, IDENTIFY DEVICE és egyéb parancsokra dobál hibákat. Emiatt firmware hibának tűnik. Volt olyan Samsung sorozat, aminél tényleg volt ilyen hiba, de az nem ez... Akinek van ugyanilyen diszkje, rá tudna nézni a SMART-jára?

Sziasztok,

adott egy, a tárgyban szereplő kontroller, amelyik kirugta mag alol az egyik raid set diszkjét, majd mikor a másik fele media errorokat kezdett dobalni, jobbnak láttuk, ha kivesszük a meghibásodott diszket (hivjuk disk1 -nek), dd -vel lementjük, de előbb még probálkoztunk azért egy reboottal.

(Annak, hogy miért következhetett mindez be, története van, de ezt nem taglalnám...)

A reboot után a raidset 3 -hoz tartozó diszket rögtön el is kezdte a raidset 1 -hez syncelni, majd a media errorok miatt leakadt. Ezt rendben le is ddztük és ennek eredményét egy másik, pass trough -ban levő diszkre toltuk át. (disk2 a továbiakban)

Mivel itt ugye már belefirkálta a raid#1 szuperblokkját/headerjét/nemtommit még, ezért ezt eltávolítottuk róla; a megfelelő mérettel (512k) eltoltuk és így, a pass trough disk valoban pass trough lett. Ennek megfelelően ujra is indítottuk, használatba akartuk venni; de nem indult el a gép.
Miután disk2 ki lett véve, elindult a gép, és felhuzta a többi raidet (6*raid1). A történet folytatásaként a pass trough -ként megjelölt és akként használt disk2 be lett rakva hot swap -ba és azonnal rá is kezdte syncelni a raid#1 -et, ami történetesen szintén szét van csúszva, de a disk2 nem lehetett a része (mivel pass trough -ként kellene ismernie).

Tehát a szituáció az, hogy bármilyen adattartalommal töltjük is fel a disk2 -t, mindenképp agresszívan a raid#1 -hez akar syncelni.

Tudtok -e valami megoldást arra, hogy elkerüljük ezt az automatikus rebuildot; pláne ugy, hogy az valojában nem is történhetne meg, mert a diszk nem tartalmazza az elején az 512 k -nyi raid metaadatot/headert,etc, és még pass troughként is kellene ismernie a kontrollernek.

Vagy: elképzelhető az is, hogy a kontroller lát egy diszket, ami pass trough, vagy bármi; nem tagja egyetlen arraynak sem, s rekvirálja egy másik tömb mellé hot spare -nak; kérdés nélkül?

Vagy: a kontroller nem csak ott tárol metaadatokat a diszkről; esetleg képes a saját eltárolt konfigját (amiben pass trough szerepel) figyelmen kívül hagyni?

A válaszokat előre is köszi!

A problémám a következő:
Adott 3db teljesen egyforma gép debian lenny-vel, soft raid-el(WD15EARS hdd-k) ebből 2 teljesn tökéletesen működik. A harmadikról viszont múlt vasárnap éjszaka szólt a nagios, hogy az egyik hdd-t nem tudja elérni. Rá ssh-ztam, láttam failed-ben van egy de már syncelődik a spare. No sebaj majd reggel kicserélem a rosszat. Reggelre lett még egy failed állapotú. Kikaptam őket megnéztem egy másik gépben a kondíciójuk a hdsentinel alapján 11%, a másikat pedig nem lehetett olvasni. Gondoltam sikerült kifogni egy szar széria WD-t, rendeltem gyorsan 1,5 TB-os samukat. Amikor megjöttek bepakoltam 2-t, megcsináltam az új tömböt és hagytam syncelődni őket. Egyszercsak látom most a 2 samuból az egyikkel erőlködik(200 KB/s sebességgel). Na gondoltam ez kábel baj lesz, hát kicseréltem őket. Az az egy samu ugyanúgy szar volt a kábelcsere után is, na mondom biztos ekkora pechem van és az 5db samuból kifogtam az egy hibásat. Szóval csere. Elindult a tömb 2 db WD-vel(100 és 93%-osak) és 2 db samuval(2 db 100%-os). Most itt tartok(a harmadik oszlop a kondíciót jelöli):

/dev/sda 30 100 23320 SAMSUNG_HD082GJ     S0VPJ9BQ108903    82580
/dev/sdb 32  98  9742 WDC_WD15EARS-00Z5B1 WD-WMAVU2824220 1430799
/dev/sdc 30  92  9743 WDC_WD15EARS-00Z5B1 WD-WMAVU2628990 1430799
/dev/sdd 19 100    74 SAMSUNG_HD154UI     S1XWJ9FZC01379  1548170
/dev/sde 19  11    74 SAMSUNG_HD154UI     S1XWJD6B300244  1548170

Közben csináltam egy upgrade-t squeeze-re, a hiba ugyanaz, X idő elteltével a raid tömbben található merevlemezek kondíciója folyamatosan csökken, egészen addig az állapotig amikor már teljesen olvashatatlan lesz. A hiba ennél az egy szervernél van a többi tökletesen működik. Esetleg valakinek valami ötlet?
Gondoltam még arra, hogy esetleg a táp szarozna(chieftec azt hiszem), de szerintem az egyszerre nyírná ki az összeset és úgy, hogy hirtelen halál lenne, nem pedig a kondíciójuk csökkenne. No meg a rendszervinyóval(sda) semmi probléma.

A smartctl kimenete az sde-re:

=== START OF INFORMATION SECTION ===
Model Family:     SAMSUNG SpinPoint F2 EG series
Device Model:     SAMSUNG HD154UI
Serial Number:    S1XWJD6B300244
Firmware Version: 1AG01118
User Capacity:    1.500.301.910.016 bytes
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   8
ATA Standard is:  ATA-8-ACS revision 3b
Local Time is:    Sun Jun 26 11:38:46 2011 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x00) Offline data collection activity
                                        was never started.
                                        Auto Offline Data Collection: Disabled.
Self-test execution status:      (   0) The previous self-test routine completed
                                        without error or no self-test has ever
                                        been run.
Total time to complete Offline
data collection:                 (20028) seconds.
Offline data collection
capabilities:                    (0x7b) SMART execute Offline immediate.
                                        Auto Offline data collection on/off support.
                                        Suspend Offline collection upon new
                                        command.
                                        Offline surface scan supported.
                                        Self-test supported.
                                        Conveyance Self-test supported.
                                        Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
                                        power-saving mode.
                                        Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                                        General Purpose Logging supported.
Short self-test routine
recommended polling time:        (   2) minutes.
Extended self-test routine
recommended polling time:        ( 255) minutes.
Conveyance self-test routine
recommended polling time:        (  35) minutes.
SCT capabilities:              (0x003f) SCT Status supported.
                                        SCT Error Recovery Control supported.
                                        SCT Feature Control supported.
                                        SCT Data Table supported.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   099   099   051    Pre-fail  Always       -       9079
  3 Spin_Up_Time            0x0007   072   072   011    Pre-fail  Always       -       9190
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       6
  5 Reallocated_Sector_Ct   0x0033   077   077   010    Pre-fail  Always       -       1010
  7 Seek_Error_Rate         0x000f   253   253   051    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0025   100   100   015    Pre-fail  Offline      -       0
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       75
 10 Spin_Retry_Count        0x0033   100   100   051    Pre-fail  Always       -       0
 11 Calibration_Retry_Count 0x0012   100   100   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       6
 13 Read_Soft_Error_Rate    0x000e   099   099   000    Old_age   Always       -       8649
183 Runtime_Bad_Block       0x0032   100   100   000    Old_age   Always       -       0
184 End-to-End_Error        0x0033   100   100   000    Pre-fail  Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       8649
188 Command_Timeout         0x0032   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   081   076   000    Old_age   Always       -       19 (Lifetime Min/Max 19/24)
194 Temperature_Celsius     0x0022   081   075   000    Old_age   Always       -       19 (Lifetime Min/Max 19/25)
195 Hardware_ECC_Recovered  0x001a   100   100   000    Old_age   Always       -       890886094
196 Reallocated_Event_Count 0x0032   076   076   000    Old_age   Always       -       1010
197 Current_Pending_Sector  0x0012   098   097   000    Old_age   Always       -       79
198 Offline_Uncorrectable   0x0030   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   253   253   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x000a   100   100   000    Old_age   Always       -       0
201 Soft_Read_Error_Rate    0x000a   087   001   000    Old_age   Always       -       905

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
No self-tests have been logged.  [To run self-tests, use: smartctl -t]


SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

Sziasztok,

Adott egy kis-közép cég 50 felhasználóval. 2 szerver (3 évesek).

1. - HP Proliant DL380G5 1x 4 magos CPU, 4 GB RAM, 3x146 Gb SAS Raid 5
- Oprendszer: Debian Linux
- Feladat: WMS adatbáziskezelés
- Kihasználtság: 10%

2. - HP Proliant DL380G5 1x 4 magos CPU, 6 GB RAM, 2x72 GB SAS Raid 1, 4x146 Gb SAS Raid 5
- Oprendszer Windows 2008 Enterprise
- Feladat: File, nyomtató szerver
- Kihasználtság: 25%

Adatmentést készítek LTO4-re.

Olyan megoldásban gondolkodom, hogy hardver hiba esetén 1 órán belül működő rendszert tudjak "varázsolni". Azaz a rendszer megbízhatóságát szeretném növelni. A meglévő szervereket is cserélném.

Keret: 2-3 Millió

Vennék két azonos szervert (két egymáshoz közeli épületben elhelyezve 50m), az egyikre VMware -t raknék és rátelepíteném a két virtuális szervert. Vennék bele 2x72 Gb SAS Raid 1, és 4x 300 GB SAS HDD-t Raid 5. A másikat meghagynám hideg tartaléknak HDD nélkül. Ha mondjuk az éles szerver alaplapja meghal akkor a HDD-ket kiszedném és átraknám a másikba. A hideg tartalék gép elindulna vele vagy az ESX felismerné, hogy megváltozott a hardver?

6-700 Gb tárhely elég lenne összesen.

Vagy inkább VMware HA clusterben kéne gondolkodnom? Biztos van jobb ötlet is.

Várom a véleményeket. Mebízható rendszerépítő cégek is érdekelnek. Köszi a segítséget!

Sziasztok!

Adott egy 2 TB winchester, amin már megvannak a RAID es particiok (softweres RAID rol van szó természetesen). A probléma ott kezdődött, hogy amit akkor feltettem Slackware current verziót a kernel mag bugos rajta, így nem indult el maga a rendszer sem. Most igazából a problémám az az, hogy usb átalakítóval telepíteném rá a javított verót, de nem ismeri fel a RAID t partícióimat. A kérdésem az, hogy tudnám erre rávenni, mivel azt írja folyamatosan, hogy a superblokkot nem találja ...

root@csillagocska:~# dmesg | tail
[ 86.268056] usb 2-1: SerialNumber: 000000000033
[ 86.268596] scsi9 : usb-storage 2-1:1.0
[ 87.268847] scsi 9:0:0:0: Direct-Access USB TO I DE/SATA Device 0041 PQ: 0 ANSI: 0
[ 87.269175] sd 9:0:0:0: Attached scsi generic sg2 type 0
[ 87.273438] sd 9:0:0:0: [sdb] Attached SCSI disk
[ 111.143839] ata1.00: configured for UDMA/100
[ 111.143847] ata1: EH complete
[ 112.173512] EXT4-fs (sda1): re-mounted. Opts: user_xattr,commit=0
[ 160.779603] iwlagn 0000:07:00.0: Aggregation not enabled for tid 0 because load = 1
[ 175.222025] iwlagn 0000:07:00.0: iwlagn_tx_agg_start on ra = 00:25:9c:b3:01:00 tid = 0
root@csillagocska:~# mdadm --assemble --auto=yes --force /dev/m0 /dev/sdb
mdadm: no recogniseable superblock on /dev/sdb
mdadm: /dev/sdb has no superblock - assembly aborted
root@csillagocska:~#

oot@csillagocska:~# fdisk -l

Disk /dev/sda: 250.1 GB, 250059350016 bytes
255 fej, 63 szektor, 30401 cilinder, összesen 488397168 szektor
Egység: szektorok 1 * 512 = 512 bájt
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Lemezazonosító: 0x21226b90

Eszköz Indítás Eleje Vége Blokkok Az Rendszer
/dev/sda1 63 117194174 58597056 83 Linux
/dev/sda2 117194175 234388349 58597087+ 83 Linux
/dev/sda3 234388350 239272109 2441880 82 Linux lapozó
/dev/sda4 239272110 488392064 124559977+ 83 Linux
root@csillagocska:~#

Nem látszanak az /dev/sdb RAID t partíciói...

A segítséget előre is köszönöm.

Van egy HP szerverünk, fent említett vezérlővel, 1 éve vettük, originál, jó drága, akksis cache, meg minden. RAID5, 3 diszkkel. 3 órával ezelőttig ment, aztán újraindult, és nem bootolt, 2 diszkre hibát jelzett. Pedig mindhárom diszken a zöld LED ég, nem a narancs. Nyomtunk egy F2-t, hogy lementsük az adatokat, így elindult a Windows. Volt rajta egy csomó virtuális gép, 10-ből 8 nem bootolt be, mert olyan apróságok hiányoztak, mint a Windows mappa, vagy a kernel. Nem kell semmi segítség, majd megoldjuk. Csak azt mondja már meg valaki, mi a *°$@-" ÉÁ!!/!+É2 $[$453$^24!+%-ra jó ez az egész RAID? 10-ből 9-szer döglik meg, mert akárhányszor valami elromlik, és felkészülünk rá, legközelebb valami súlyosabb módon száll el az egész. Csak a széfben tartott backupra lehet számítani...

Adott egy Maxtor 6V080E0 80gb-os, SATA2-es merevlemez. Rajta van az operációs rendszer, a személyes dolgaimat egy másik 250gb-os Western Digitalon tárolom. Az a gond, hogy ma épp egy haveromnak akartam cd-t írni, viszont hirtelen az egész rendszer belassult, a cd írás hibával dobott vissza és lefagyott. Kikapcsoltam az egészet, majd bekapcsolás után a rendszer felállásáig eltelt legalább 15 perc. Végülis elindult. Azt vettem észre, hogy az átlagsebesség jelentősen alábbadott, a játékok meglehetősen nyögvenyelősen viselik el a harddisk műveleteket, beszaggatnak minden írás/olvasáskor. Elindítottam a HDD Regeneratort a javulás reményében, viszont azt a lassúságot már leírni is nehéz. A százalékmutató körülbelül minden 15 percben ugrott, jól meg is állítottam 7%-nál.

Everestben hozzámértem a szóban forgó "döglődő" merevlemez sebességét a gépemben lévő másikéhoz (amire a HDDSentinel azt mondta még tavaly, hogy totálisan le van használva, alig van 15 napja hátra - a sors fintora, hogy még mindig tökéletesen működik, igaz van 1 offline sector). A Western Digital lineáris olvasásnál átlag 60 Mb/s-al olvasott (pufferelten 193 Mb/s - 19 ms-os elérési idővel) míg a Maxtor a lineáris olvasásnál kemény 3,5 Mb/s-ot produkált (pufferelten 3,8 Mb/s - 17 ms-os elérési idővel).

Szóval a konkrét kérdés az lenne, hogy egyik pillanatról a másikra mitől csinál ilyet egy merevlemez és, hogy mi módon, egyáltalán valahogy menthető-e még? Nincs most pénzem új SATA-s merevlemezt venni, házon belül csak ATA-s van, a gépben meg csak egy IDE csatorna lelhető fel. Ha DVD íróval ugyanarra kötöm, akkor egyszerre csak egyiket tudja használni, ami mondjuk zenehallgatásnál azért idegesítő tud lenni (míg felpörög a dvd addig bekussol a mnyúzik). Valaki tud valami megoldást? :)

Előre is köszi!

Sziasztok!

2x 1TB-os SATA2/3 HDD-vel bővíteném az itthoni HOME (ismétlem HOME) szerveremet. 0-24-ben ben megy, és NAS-ként (IS) szolgálna ezentúl.

Asztali gépemben 2 WD HDD ketyeg:
-(WD1600JS) kb 3 éve, kifogástalanul működik.
-(WD5002ABYS) kb 1,5 éve, és szintén hibátlanul megy. Egyiken sincs badsactor.

Én szívem szerint WD-t vennék, de nagyon nagyon jókat hallottam a Hitachiról is.
Ti mit ajánlotok? LÉGYSZI CSAK OLYANOK kommenteljenek akiknek MINDKÉT HDD-vel van tapasztalata. <--Ez lenne az 1. kérdésem.

WD-ből ugyebár van 3 típus: Caviar Green/Blue/Black
Az, hogy mennyire energiatakarékos nem érdekel. Tehát marad a Black/Blue. Mit gondoltok érdemes +10K-val többet kiadni a BLACK-ért? (Ér ennyit a több CACHE, ill. a több GARANCIA? Vagy van még valami amivel többet tud a BLACK a BLUE-nál? ) <-- Ez lenne az 2. kérdésem

Előre is köszönöm a segítségeteket!

----------------------------------------------------------------

Update1+2: (leszűkítve) A választható HDD-k köre így módosult

+WD Caviar Black
-1TB, típus: WD1002FAEX
----------------
+Hitachi Deskstar:
-1TB, típus: 7K1000.C -> Modell: HDS721010CLA332 <---- A 32 MB cache miatt inkább az 1.5 TB-osat választanám hiszen abban több cache van.
Még valami FONTOS különbség?
http://www.hitachigst.com/internal-drives/desktop/deskstar/deskstar-7k1…
http://www.hitachigst.com/internal-drives/desktop/deskstar/deskstar-7k3…
-1.5TB, típus: 7K3000 -> Modell: HDS723015BLA642

Szóval ezekből kell választanom

Üdv.:
V007

Sziasztok,
van valakinek tapasztalata QNAP TS-410 , 412-es NAS-ok valamelyikevel, hogy hogyan viselkednek aramszunet, vagy diszk kieses eseten?
Diszkeket raid5-be szeretnek ossze huzni (FS=ext3), de mivel fontos hogy a rajta levo adat valamilyen modon 1 diszk halala eseten tutira visszanyerheto legyen, gondoltam feldobom itt ezt a postot hogy van-e tapasztalat.

pl hogy viselkedik egy ilyen rendszer aramszunet eseten? (ok, lesz UPS, de megis... mire szamitsak?)

dolt mar be valakinek ilyen?