mdadm vinyócsere után félbeszakad a szinkronizálás

Debian GNU/Linux

Sziasztok,
A következő furcsa jelenséget tapasztalom.
Lenny alatt van egy sima RAID1 tömböm két db 1 terás vinyóval:
/dev/md0 : /dev/sda1 és /dev/sdb1

Namost a /dev/sdb1 szegény elhalálozott, az mdadm szépen értesített is, hogy megjelölte faulty-nak, és kivette a tömbből.

Garanciális csere után berakom a lemezt, szépen létrehozom a partíciót, pont ugyanakkorára, fájlrendszert.

mdadm --manage /dev/md0 --add /dev/sdb1

Szépen be is vette, elkezdett szinkronizálni. (350percet írt ki.)
Néha ránéztem, utoljára 12%-nál tartott.
Mikor legközelebb ránéztem, végzett-e már, a következőt látom.

# cat /proc/mdstat

Personalities : [raid1]
md0 : active raid1 sda1[0] sdb1[2]
971683392 blocks [2/1] [U_]

unused devices:

# mdadm -Q --detail /dev/md0
/dev/md0:
Version : 0.90
Creation Time : Sat Jul 4 11:36:37 2009
Raid Level : raid1
Array Size : 971683392 (926.67 GiB 995.00 GB)
Used Dev Size : 971683392 (926.67 GiB 995.00 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 0
Persistence : Superblock is persistent

Update Time : Tue May 4 09:14:16 2010
State : clean, degraded
Active Devices : 1
Working Devices : 2
Failed Devices : 0
Spare Devices : 1

UUID : 126ef3fe:6e66c049:97b832c4:22c6cc43
Events : 0.3812513

Number Major Minor RaidDevice State
0 8 1 0 active sync /dev/sda1
2 8 17 1 spare rebuilding /dev/sdb1

Tehát olyan, mintha még csinálná, de a State-nél már nem írja, hogy synching, ugyanakkor itt alul a State-nél azt írja rebuilding, viszont eltűnt a progress-t mutató sor is.

Kicsit nem értem, új vinyót tettem bele.

A messages tartalma az alábbi bejegyzés másodpercenként 4x:

May 4 09:34:04 localhost kernel: [11902.377282] RAID1 conf printout:
May 4 09:34:04 localhost kernel: [11902.377296] --- wd:1 rd:2
May 4 09:34:04 localhost kernel: [11902.377306] disk 0, wo:0, o:1, dev:sda1
May 4 09:34:04 localhost kernel: [11902.377315] disk 1, wo:1, o:1, dev:sdb1
May 4 09:34:04 localhost kernel: [11902.377320] RAID1 conf printout:
May 4 09:34:04 localhost kernel: [11902.377325] --- wd:1 rd:2
May 4 09:34:04 localhost kernel: [11902.377333] disk 0, wo:0, o:1, dev:sda1
May 4 09:34:04 localhost kernel: [11902.377341] disk 1, wo:1, o:1, dev:sdb1
May 4 09:34:05 localhost kernel: [11902.609534] RAID1 conf printout:
May 4 09:34:05 localhost kernel: [11902.609548] --- wd:1 rd:2
May 4 09:34:05 localhost kernel: [11902.609558] disk 0, wo:0, o:1, dev:sda1
May 4 09:34:05 localhost kernel: [11902.609566] disk 1, wo:1, o:1, dev:sdb1
May 4 09:34:05 localhost kernel: [11902.609571] RAID1 conf printout:
May 4 09:34:05 localhost kernel: [11902.609577] --- wd:1 rd:2
May 4 09:34:05 localhost kernel: [11902.609584] disk 0, wo:0, o:1, dev:sda1
May 4 09:34:05 localhost kernel: [11902.609592] disk 1, wo:1, o:1, dev:sdb1

Vajon mit nem veszek észre?

Előre is köszönöm!
Üdv,
Optimista

  • 1433 megtekintés

( elod v | 2010. 05. 04., k – 09:38 )

a SMART nem mutat uncorrectable-t a forrás lemezen?

Szia elod!
Először is köszi a választ, igazad volt!
Lefuttattam egy short testet a forrás lemezen, és voilá egy read error...:

SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed: read failure 20% 3239 920726326

Gyanús a vezérlő is, ez egy régebbi p3-as gép, és kb. 3 hónapja cseréltem benne a PCI-os RAID vezérlőt, mert furcsa hibákat generált. Azóta rendben volt, de ugyanolyanra cserélték azt is gariban, és hát nem volt valami drága darab, bár elvileg Silicon chipes, de hát...

Köszönettel:
Optimista

Bevallom, tippeltem :).

A gyors eszmefuttatás az volt, hogy ugye a fene se olvassa végig az adatokat (így nem tudja meg a kernel sem, hogy hiba van) de szinkronizáláskor bizony végigmegy rajta.

A továbbiakban érdemes lehet éjszakánként cron-ból pár naponta egy hosszú SMART tesztet végignyomni rajta.

Igen, ez jó ötlet, meg is fogadom, csak előbb helyre kell pofoznom a rendszert.
(Közben megtaláltam az unrecoverable errort, ahogy leállt a legutóbb indított szinkronizálás kb. 45%-nál.)

Az az érzésem, hogy nem a lemez hibás, hanem a SATA vezérlő! (Említettem, ez egy régebbi p3-as compaq desktop gép, nincs SATA vezérlő az alaplapon)

Persze nem vagyok biztos benne, de a következők miatt gondolom:

- Az első vezérlőkártya pár hónapja meghalt. Fura hibákat jelzett a log, de azok valahogy egyértelműen a kártyára utaltak. Kicseréltem, megjavult.
- A mostani egy pontosan ugyanolyan kártya, így a bizalmam elég gyenge lábakon áll... (Noname 4500 forintos PCI kártya Silicon chippel.)
- A vinyók Samsungok, 9 hónaposak, és otthoni szerver, szóval nincs nagyüzem, csak egy sima samba fájlszervernek használom, szóval nem egy extrém terhelésnek kitett vasról van szó.
- Mivel tegnap cseréltem automatikusan gariba az egyik diszket, valahogy gyanús, hogy a másik is hibázna, ilyen fiatalon. (3200 órát ment)

Szerinted milyen kártyát érdemes venni? Van esetleg valami nevesebb, amire érdemes beruházni? Nem szívesen kockáztatnám az adatbiztonságot, sok munkámat is erre a gépre mentem (plusz az összes családi fotó, gyerek, kutya, ahogy felnőnek...)

Köszönettel!
Optimista

( Cseresznye | 2010. 05. 04., k – 16:28 )

Sziasztok!
Nem akarok egy új topic-ot nyitni.
Mennyire ajánlott használat közben ("on-the-fly") soft raid1-et létrehozni?
Több helyen olvastam, hogy csak olvasásra mount-olt meghajtóval érdemes belekezdeni.
(esetleg, ha valakinek van türelme, leírhatná a lépéseket, mielőtt nekiállok guglizni..)

Minden matatás a storage-on csak és kizárólag mentés után, kis terheléssel javasolt. Nem azért, mert baj lesz - sokkal inkább azért, mert baj lehet. (attól, hogy van olyan, aki on the fly költöztet egyik storage-ról a másikra némi lvm-es trükközéssel SAP alatt Oracle-t, attól még az nem követendő példa :-))

( optimista | 2010. 05. 05., sze – 08:41 )

Csak elmesélem, hogyan oldottam meg, hátha más is belefut.

1. Vettem egy új SATA vezérlőt, és cseréltem, biztos, ami biztos. :)
2. Kivettem az új, hibátlan vinyót a tömbből, hogy ne kezdjen el mindig szinkronizálni:
mdadm --manage /dev/md0 -f /dev/sdb1
mdadm --manage /dev/md0 -r /dev/sdb1
3. Kézzel javítottam a sérült blokkokat (7db volt, szerencsére egyiken sem volt adat)
Ezt a leírást használtam, kb. fél óra alatt megvolt:
http://smartmontools.sourceforge.net/badblockhowto.html
4. Új vinyó vissza a tömbbe:
mdadm --manage /dev/md0 -a /dev/sdb1
5. Ekkor már rendben lefutott a szinkronizálás

És halleluja:

SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed without error 00% 3260 -
# 2 Short offline Completed: read failure 20% 3260 920882614
# 3 Short offline Completed: read failure 20% 3260 920770380
# 4 Offline Aborted by host 90% 3260 -
# 5 Short offline Completed: read failure 20% 3259 920726327
# 6 Short offline Completed: read failure 20% 3258 920726326
# 7 Short offline Completed: read failure 20% 3258 920726326
# 8 Short offline Completed: read failure 20% 3251 920726326
# 9 Extended offline Completed: read failure 90% 3241 920726326
#10 Short offline Completed: read failure 20% 3239 920726326

Remélem senki nem fut bele ilyenbe, de ha mégis, megússza kevesebb szívással!

Köszönöm a tanácsokat!

Üdv:
Optimista

Akartam mondani hogy s mint, de sokkal jobb, mikor saját magadnak fedezed fel.

Eddig csak egyszer-kétszer használtam a debugfs-t. Na ilyenkor szokás háromszor megnézni a paramétereket mielőtt elmerészkedik az ember ujja az enter felé :).

Egyébként nem hinném, hogy a vezérlő lenne, bár nekem is volt érdekes (rossz) tapasztalatom valami 2 sata-s sil vezérlővel p3-on.