Nejprve, jak jsem se do této situace dostal:
Měl jsem pole RAID5 s disky každý 2TB (externí USB disky), chtěl jsem pak vytvořit větší šifrované pole. Dostal jsem proto 2 další disky (také 2 TB každý) a plán byl spustit původní pole v degradovaném režimu, nastavit nové šifrované pole, zkopírovat část dat, poté původní pole zmenšit na 2 disky v degradovaném režimu, zvětšit nový, zkopírovat zbytek dat a nakonec zvětšit na 7 disků RAID5 nedegradovaných. Celý postup jsem provedl pomocí /dev/loopX zařízení po 2 GB, abych otestoval, zda má můj plán nějaké výhrady.
Se skutečným polem šlo všechno dobře až do bodu, kdy jeden z nových disků selhal. Když jsem nahradil tento, pořadí, ve kterém jsou disky rozpoznávány jádrem, se po příštím restartu změnilo (/dev/sdb , /dev/sdc , … byly všechny jiné disky než dříve). Všechno se pokazilo a neuvědomil jsem si to, dokud se jeden z disků znovu nesynchronizoval jako člen nesprávného pole. Ušetřím si podrobnosti tohoto příběhu a přejdu rovnou k věci:
Nyní mám jedno šifrované pole, 3diskové RAID5, degradované na /dev/sdc1 a /dev/sdd1 , běží naprosto v pořádku, všechna data tam a zdravý souborový systém podle fsck -f .
Zatím dobrý.
Celý problém je nyní na 3 discích – nemohu znovu zprovoznit toto nešifrované pole. Jsem si docela jistý, že data MÁ být tam na /dev/sdf1 , /dev/sdg1 , /dev/sdh1 , protože to bylo funkční pole těsně předtím, než se JEDEN z disků mohl pokazit (náhodně byl znovu synchronizován jako člen druhého šifrovaného pole, jak bylo řečeno dříve). Takže jeden z těchto tří disků může mít nesprávná data pole, ale který z nich? A dva z nich musí být dobré, ale jak na to mám přijít?
Vyzkoušel jsem každou permutaci mdadm --create … pomocí /dev/sdf1 , /dev/sdg1 , /dev/sdh1 a „chybějící“ jako:
mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/sdf1 /dev/sdg1 missing
mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/sdf1 missing /dev/sdg1
...a samozřejmě pokaždé zkontrolovat pomocí
fsck /dev/md0
která si stěžovala na neplatný superblok.
Pokaždé, když mdadm vytvořilo pole, ale nebyl čitelný žádný souborový systém, obsahovalo jen odpadky, žádná z permutací použitých s mdadm nakonec nefungovala.
Moje otázka tedy zní:Jaké možnosti mi zbývají? Kromě toho, že ztratím svá data a znovu sestavím pole od nuly, samozřejmě.
Zde několik dalších informací (všechny disky):
mdadm --examine /dev/sdb1
/dev/sdb1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : cfee26c0:414eee94:e470810c:17141589
Name : merlin:0 (local to host merlin)
Creation Time : Sun Oct 28 11:38:32 2012
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 3906760704 (1862.89 GiB 2000.26 GB)
Array Size : 3906759680 (3725.78 GiB 4000.52 GB)
Used Dev Size : 3906759680 (1862.89 GiB 2000.26 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : f4f0753e:56b8d6a5:84ec2ce8:dbc933f0
Update Time : Sun Oct 28 11:38:32 2012
Checksum : 60093b72 - correct
Events : 0
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : AA. ('A' == active, '.' == missing)
mdadm --examine /dev/sdc1
/dev/sdc1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 5cb45bae:7a4843ba:4ad7dbfb:5c129d2a
Name : merlin:1 (local to host merlin)
Creation Time : Wed Sep 26 07:32:32 2012
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 3906760704 (1862.89 GiB 2000.26 GB)
Array Size : 3905299456 (3724.38 GiB 3999.03 GB)
Used Dev Size : 3905299456 (1862.19 GiB 1999.51 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 9e2f9ae6:6c95d05e:8d83970b:f1308de0
Update Time : Fri Oct 26 03:26:37 2012
Checksum : 79d4964b - correct
Events : 220
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 0
Array State : AA. ('A' == active, '.' == missing)
mdadm --examine /dev/sdd1
/dev/sdd1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 5cb45bae:7a4843ba:4ad7dbfb:5c129d2a
Name : merlin:1 (local to host merlin)
Creation Time : Wed Sep 26 07:32:32 2012
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 3906760704 (1862.89 GiB 2000.26 GB)
Array Size : 3905299456 (3724.38 GiB 3999.03 GB)
Used Dev Size : 3905299456 (1862.19 GiB 1999.51 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 98b07c41:ff4bea98:2a765a6b:63d820e0
Update Time : Fri Oct 26 03:26:37 2012
Checksum : 6e2767e8 - correct
Events : 220
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : AA. ('A' == active, '.' == missing)
mdadm --examine /dev/sde1
/dev/sde1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 6db9959d:3cdd4bc3:32a241ad:a9f37a0c
Name : merlin:0 (local to host merlin)
Creation Time : Sun Oct 28 12:12:59 2012
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 3905299943 (1862.19 GiB 1999.51 GB)
Array Size : 3905299456 (3724.38 GiB 3999.03 GB)
Used Dev Size : 3905299456 (1862.19 GiB 1999.51 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 677a4410:8931e239:2c789f83:e130e6f7
Update Time : Sun Oct 28 12:12:59 2012
Checksum : 98cb1950 - correct
Events : 0
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 2
Array State : A.A ('A' == active, '.' == missing)
mdadm --examine /dev/sdf1
/dev/sdf1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 3700a0a6:3fadfd73:bc74b618:a5526767
Name : merlin:0 (local to host merlin)
Creation Time : Sun Oct 28 11:28:30 2012
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 3905392640 (1862.24 GiB 1999.56 GB)
Array Size : 3905391616 (3724.47 GiB 3999.12 GB)
Used Dev Size : 3905391616 (1862.24 GiB 1999.56 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 5a8a5423:10b7a542:26b5e2b3:f0887121
Update Time : Sun Oct 28 11:28:30 2012
Checksum : 8e90495f - correct
Events : 0
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : AA. ('A' == active, '.' == missing)
mdadm --examine /dev/sdg1
/dev/sdg1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 202255c9:786f474d:ba928527:68425dd6
Name : merlin:0 (local to host merlin)
Creation Time : Sun Oct 28 11:24:36 2012
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 3905299943 (1862.19 GiB 1999.51 GB)
Array Size : 3905299456 (3724.38 GiB 3999.03 GB)
Used Dev Size : 3905299456 (1862.19 GiB 1999.51 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 4605c729:c290febb:92901971:9a3ed814
Update Time : Sun Oct 28 11:24:36 2012
Checksum : 38ba4d0a - correct
Events : 0
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : AA. ('A' == active, '.' == missing)
mdadm --examine /dev/sdh1
/dev/sdh1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 682356f5:da2c442e:7bfc85f7:53aa9ea7
Name : merlin:0 (local to host merlin)
Creation Time : Sun Oct 28 12:13:44 2012
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 3906761858 (1862.89 GiB 2000.26 GB)
Array Size : 3906760704 (3725.78 GiB 4000.52 GB)
Used Dev Size : 3906760704 (1862.89 GiB 2000.26 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 489943b3:d5e35022:f52c917a:9ca6ff2a
Update Time : Sun Oct 28 12:13:44 2012
Checksum : f6947a7d - correct
Events : 0
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 1
Array State : AA. ('A' == active, '.' == missing)
cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdc1[0] sdd1[1]
3905299456 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
unused devices: <none>
Jakákoli pomoc by byla velmi oceněna!
Související:Proč rsync neumožňuje velikost bloku> 128 kB?Přijatá odpověď:
Pokud jste právě ztratili jeden disk, měli byste se z toho dokázali zotavit pomocí mnohem bezpečnějšího --assemble .
Spustili jste nyní vytvořit tolik, že všechna UUID se liší. sdc1 a sdd1 sdílet UUID (očekává se, protože to je vaše pracovní pole)… ostatní disky sdílejí název, ale všechny mají jiné UUID. Takže předpokládám, že žádný z nich není původní superblok. Škoda…
Každopádně bych hádal, že se buď pokoušíte použít špatné disky, nebo se pokoušíte použít špatnou velikost chunku (výchozí nastavení se podle mě časem změnilo). Vaše staré pole také mohlo používat jinou verzi superbloku – tato výchozí hodnota se rozhodně změnila – což mohlo kompenzovat všechny sektory (a také zničit některá data). Nakonec je možné, že používáte špatné rozvržení, i když je to méně pravděpodobné.
Je také možné, že vaše testovací pole bylo čtení a zápis (z hlediska md), že pokusy o použití ext3 skutečně provedly nějaké zápisy. Například záznam v deníku. Ale to je pouze v případě, že v určitém okamžiku najde superblok, myslím.
BTW:Myslím, že byste opravdu měli používat --assume-clean , i když se degradované pole samozřejmě nepokusí zahájit přestavbu. Pak pravděpodobně budete chtít okamžitě nastavit pouze pro čtení.