Ok - coś mnie wkurzało w związku z twoim problemem, więc odpaliłem maszynę wirtualną, aby zanurkować w zachowanie, którego należy się spodziewać. Zaraz dojdę do tego, co mnie wkurzało; najpierw pozwól mi powiedzieć:
Wykonaj kopię zapasową tych dysków przed próbą czegokolwiek !!
Możliwe, że już wyrządziłeś szkody poza tym, co zrobiła ponowna synchronizacja; czy możesz wyjaśnić, co miałeś na myśli, mówiąc:
Zgodnie z sugestiami wyczyściłem superbloki i odtworzyłem tablicę z opcją --assume-clean, ale bez powodzenia.
Jeśli prowadziłeś a mdadm --misc --zero-superblock, powinieneś być w porządku.
W każdym razie, odszukaj kilka nowych dysków i chwyć ich dokładne bieżące obrazy, zanim zrobisz cokolwiek, co może zrobić więcej zapisu na tych dyskach.
dd if=/dev/sdd of=/path/to/store/sdd.img
To powiedziawszy ... wygląda na to, że dane przechowywane na tych rzeczach są szokująco odporne na błędne resynchronizacje. Czytaj dalej, jest nadzieja i może to być dzień, w którym osiągnąłem limit długości odpowiedzi.
Najlepszy scenariusz
Rzuciłem maszynę wirtualną, aby odtworzyć scenariusz. Dyski mają tylko 100 MB, więc nie czekałbym wiecznie przy każdej ponownej synchronizacji, ale w przeciwnym razie powinna to być dość dokładna reprezentacja.
Zbuduj tablicę tak ogólnie i domyślnie, jak to możliwe - fragmenty 512 tys., Układ symetryczny lewy, dyski w kolejności literowej. Nic specjalnego.
root@test:~# mdadm --create /dev/md0 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid5 sdd1[3] sdc1[1] sdb1[0]
203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>
Jak na razie dobrze; stwórzmy system plików i umieśćmy na nim trochę danych.
root@test:~# mkfs.ext4 /dev/md0
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=512 blocks, Stripe width=1024 blocks
51000 inodes, 203776 blocks
10188 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67371008
25 block groups
8192 blocks per group, 8192 fragments per group
2040 inodes per group
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 30 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
root@test:~# mkdir /mnt/raid5
root@test:~# mount /dev/md0 /mnt/raid5
root@test:~# echo "data" > /mnt/raid5/datafile
root@test:~# dd if=/dev/urandom of=/mnt/raid5/randomdata count=10000
10000+0 records in
10000+0 records out
5120000 bytes (5.1 MB) copied, 0.706526 s, 7.2 MB/s
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
Dobrze. Mamy na nim system plików i niektóre dane („dane” datafilei losowe dane o wartości 5 MB z tym hashem SHA1 randomdata); zobaczmy, co się stanie, gdy dokonamy odtworzenia.
root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md0
mdadm: stopped /dev/md0
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
unused devices: <none>
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 21:07:06 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 21:07:06 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 21:07:06 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdd1[2] sdc1[1] sdb1[0]
203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>
Ponowna synchronizacja zakończyła się bardzo szybko z tymi małymi dyskami, ale tak się stało. Oto, co mnie wcześniej denerwowało; twój fdisk -lwynik. mdOczekuje się, że brak tablicy partycji na urządzeniu nie stanowi żadnego problemu. Twój system plików znajduje się bezpośrednio na fałszywym urządzeniu blokowym bez tablicy partycji.
root@test:~# fdisk -l
...
Disk /dev/md1: 208 MB, 208666624 bytes
2 heads, 4 sectors/track, 50944 cylinders, total 407552 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 524288 bytes / 1048576 bytes
Disk identifier: 0x00000000
Disk /dev/md1 doesn't contain a valid partition table
Tak, brak tablicy partycji. Ale...
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
Idealnie poprawny system plików po ponownej synchronizacji. To dobrze; sprawdźmy nasze pliki danych:
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
Solidny - w ogóle brak uszkodzenia danych! Ale dzieje się tak z dokładnie tymi samymi ustawieniami, więc nic nie było odwzorowane inaczej między dwiema grupami RAID. Opuśćmy to, zanim spróbujemy to zepsuć.
root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
Cofając się
Zanim spróbujemy to przełamać, porozmawiajmy o tym, dlaczego trudno to przełamać. RAID 5 działa przy użyciu bloku parzystości, który chroni obszar o tym samym rozmiarze co blok na każdym innym dysku w macierzy. Parzystość nie jest tylko na jednym konkretnym dysku, jest równomiernie obracana wokół dysków, aby lepiej rozłożyć obciążenie odczytu na dyskach podczas normalnej pracy.
Operacja XOR do obliczenia parzystości wygląda następująco:
DISK1 DISK2 DISK3 DISK4 PARITY
1 0 1 1 = 1
0 0 1 1 = 0
1 1 1 1 = 0
Zatem parzystość jest rozłożona na dyski.
DISK1 DISK2 DISK3 DISK4 DISK5
DATA DATA DATA DATA PARITY
PARITY DATA DATA DATA DATA
DATA PARITY DATA DATA DATA
Ponowna synchronizacja jest zwykle wykonywana podczas wymiany martwego lub brakującego dysku; Robi się to również w mdadm createcelu zapewnienia, że dane na dyskach są zgodne z geometrią RAID. W takim przypadku ostatnim dyskiem w specyfikacji macierzy jest dysk „zsynchronizowany” - do synchronizacji wykorzystywane są wszystkie istniejące dane na innych dyskach.
Zatem wszystkie dane na „nowym” dysku są usuwane i odbudowywane; albo budowanie świeżych bloków danych z bloków parzystości dla tego, co powinno tam być, albo budowanie świeżych bloków parzystości.
Fajne jest to, że procedura dla obu tych rzeczy jest dokładnie taka sama: operacja XOR na danych z reszty dysków. Proces resynchronizacji w tym przypadku może mieć w swoim układzie, że określony blok powinien być blokiem parzystości, i myślę, że buduje nowy blok parzystości, podczas gdy w rzeczywistości odtwarza stary blok danych. Więc nawet jeśli myśli, że to buduje:
DISK1 DISK2 DISK3 DISK4 DISK5
PARITY DATA DATA DATA DATA
DATA PARITY DATA DATA DATA
DATA DATA PARITY DATA DATA
... może to być po prostu przebudowa DISK5z powyższego układu.
Dlatego dane mogą pozostać spójne, nawet jeśli tablica jest źle zbudowana.
Rzucanie małpy w dzieła
(nie klucz; cała małpa)
Test 1:
Zróbmy tablicę w niewłaściwej kolejności! sdc, a sddnastępnie sdb…
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdc1 /dev/sdd1 /dev/sdb1
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:06:34 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:06:34 2012
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:06:34 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdb1[3] sdd1[1] sdc1[0]
203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>
Ok, to wszystko dobrze i dobrze. Czy mamy system plików?
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/md1
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
Nie! Dlaczego? Ponieważ chociaż wszystkie dane są dostępne, są one w niewłaściwej kolejności; to, co kiedyś było 512 KB A, a następnie 512 KB B, A, B i tak dalej, zostało teraz przetasowane do B, A, B, A. Dysk wygląda teraz jak szarpanie się do kontrolera systemu plików, nie będzie działać. Dane wyjściowe mdadm --misc -D /dev/md1dają nam więcej szczegółów; To wygląda tak:
Number Major Minor RaidDevice State
0 8 33 0 active sync /dev/sdc1
1 8 49 1 active sync /dev/sdd1
3 8 17 2 active sync /dev/sdb1
Kiedy powinno to wyglądać tak:
Number Major Minor RaidDevice State
0 8 17 0 active sync /dev/sdb1
1 8 33 1 active sync /dev/sdc1
3 8 49 2 active sync /dev/sdd1
To wszystko dobrze i dobrze. Tym razem nadpisaliśmy całą masę bloków danych nowymi blokami parzystości. Utwórz ponownie, teraz we właściwej kolejności:
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:11:08 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:11:08 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:11:08 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
Zgrabnie, wciąż tam jest system plików! Nadal masz dane?
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
Sukces!
Test 2
Ok, zmieńmy wielkość porcji i zobaczmy, czy to nas zepsuje.
root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=64 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:21:19 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:21:19 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:21:19 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/md1
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
Tak, tak, jest ustawiony tak, jak skonfigurowano w ten sposób. Ale czy możemy wyzdrowieć?
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:21:51 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:21:51 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:21:51 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
Sukces ponownie!
Test 3
To jest ten, o którym myślałem, że na pewno zabije dane - zróbmy inny algorytm układu!
root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --layout=right-asymmetric --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:32:34 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:32:34 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:32:34 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdd1[3] sdc1[1] sdb1[0]
203776 blocks super 1.2 level 5, 512k chunk, algorithm 1 [3/3] [UUU]
unused devices: <none>
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
Superblock has an invalid journal (inode 8).
Straszne i złe - myśli, że coś znalazło i chce coś naprawić! Ctrl+ C!
Clear<y>? cancelled!
fsck.ext4: Illegal inode number while checking ext3 journal for /dev/md1
Ok, kryzys uniknął. Zobaczmy, czy dane są nadal nienaruszone po ponownej synchronizacji z niewłaściwym układem:
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:33:02 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:33:02 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:33:02 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
Sukces!
Test 4
Udowodnijmy również, że zerowanie superbloku nie jest szkodliwe naprawdę szybko:
root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --misc --zero-superblock /dev/sdb1 /dev/sdc1 /dev/sdd1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
Tak, nic wielkiego.
Test 5
Rzućmy na to wszystko, co mamy. Wszystkie 4 poprzednie testy łącznie.
- Zła kolejność urządzeń
- Zły rozmiar porcji
- Błędny algorytm układu
- Zerowane superbloki (zrobimy to między obiema kreacjami)
Naprzód!
root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --misc --zero-superblock /dev/sdb1 /dev/sdc1 /dev/sdd1
root@test:~# mdadm --create /dev/md1 --chunk=64 --level=5 --raid-devices=3 --layout=right-symmetric /dev/sdc1 /dev/sdd1 /dev/sdb1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdb1[3] sdd1[1] sdc1[0]
204672 blocks super 1.2 level 5, 64k chunk, algorithm 3 [3/3] [UUU]
unused devices: <none>
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/md1
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
Werdykt?
root@test:~# mdadm --misc --zero-superblock /dev/sdb1 /dev/sdc1 /dev/sdd1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdd1[3] sdc1[1] sdb1[0]
203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 13/51000 files, 17085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
Łał.
Wygląda więc na to, że żadne z tych działań w żaden sposób nie uszkodziło danych. Szczerze mówiąc, byłem bardzo zaskoczony tym wynikiem; Spodziewałem się umiarkowanych szans na utratę danych przy zmianie wielkości porcji i pewną wyraźną utratę przy zmianie układu. Nauczyłem się dziś czegoś.
Więc .. Jak mogę uzyskać moje dane?
Bardzo dużo informacji na temat starego systemu byłoby bardzo pomocne. Jeśli znasz typ systemu plików, jeśli masz jakieś stare kopie /proc/mdstatz informacjami o kolejności dysków, algorytmie, wielkości porcji i wersji metadanych. Czy masz skonfigurowane powiadomienia e-mail mdadm? Jeśli tak, znajdź starą; jeśli nie, sprawdź /var/spool/mail/root. Sprawdź, ~/.bash_historyczy jest tam oryginalna wersja.
Lista rzeczy, które powinieneś zrobić:
- Wykonaj kopię zapasową dysków
ddprzed zrobieniem czegokolwiek !!
- Spróbuj
fsckużyć bieżącego, aktywnego md - być może właśnie zdarzyło Ci się budować w takiej samej kolejności jak poprzednio. Jeśli znasz typ systemu plików, jest to pomocne; użyj tego konkretnego fscknarzędzia. Jeśli którekolwiek z narzędzi oferuje coś do naprawy, nie pozwól im, dopóki nie masz pewności, że faktycznie znalazły prawidłowy system plików! Jeśli fsckoferujesz coś dla ciebie, nie wahaj się zostawić komentarza z pytaniem, czy to rzeczywiście pomaga, czy tylko nuke danych.
- Spróbuj zbudować tablicę z różnymi parametrami. Jeśli masz stary
/proc/mdstat, możesz po prostu naśladować to, co pokazuje; jeśli nie, to jesteś trochę w ciemności - wypróbowanie wszystkich różnych zamówień dysków jest rozsądne, ale sprawdzanie każdego możliwego rozmiaru porcji przy każdym możliwym zamówieniu jest daremne. Dla każdego fscksprawdź, czy dostaniesz coś obiecującego.
To tyle. Przepraszamy za powieść, jeśli masz pytania, zostaw komentarz. Powodzenia!
przypis: poniżej 22 tysięcy znaków; 8k + powyżej limitu długości