Ok - qualcosa mi infastidiva per il tuo problema, quindi ho avviato una VM per immergermi nel comportamento che ci si aspettava. Arriverò a quello che mi stava infastidendo in un minuto; prima lasciami dire questo:
Eseguire il backup di queste unità prima di provare qualsiasi cosa !!
Potresti aver già fatto un danno oltre a quello che ha fatto la risincronizzazione; puoi chiarire cosa intendevi quando hai detto:
Per suggerimenti ho ripulito i superblocchi e ho ricreato l'array con l'opzione --assume-clean ma senza fortuna.
Se hai eseguito un mdadm --misc --zero-superblock, allora dovresti stare bene.
Ad ogni modo, cerca alcuni nuovi dischi e acquisisci esattamente le loro attuali immagini prima di fare qualsiasi cosa che possa fare di più scrivendo su questi dischi.
dd if=/dev/sdd of=/path/to/store/sdd.img
Detto questo, sembra che i dati archiviati su queste cose siano incredibilmente resistenti alle risincronizzazioni ribelli. Continua a leggere, c'è speranza, e questo potrebbe essere il giorno in cui ho raggiunto il limite di lunghezza della risposta.
Lo scenario migliore
Ho creato una VM per ricreare il tuo scenario. Le unità sono solo 100 MB, quindi non aspetterei per sempre ad ogni risincronizzazione, ma altrimenti dovrebbe essere una rappresentazione abbastanza accurata.
Costruito l'array nel modo più generico e predefinito possibile: 512k blocchi, layout simmetrico sinistro, dischi in ordine di lettera .. niente di speciale.
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>
Fin qui tutto bene; creiamo un filesystem e mettiamo alcuni dati su di esso.
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
Ok. Abbiamo un filesystem e alcuni dati ("dati" dentro datafile, e 5 MB di dati casuali con quell'hash SHA1 dentro randomdata) su di esso; vediamo cosa succede quando facciamo una ricostruzione.
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>
La risincronizzazione si è conclusa molto rapidamente con questi piccoli dischi, ma si è verificato. Quindi, ecco cosa mi infastidiva da prima; la tua fdisk -luscita. Non avere alcuna tabella delle partizioni sul mddispositivo non è affatto un problema, è previsto. Il tuo filesystem risiede direttamente sul dispositivo a blocchi falsi senza tabella delle partizioni.
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
Sì, nessuna tabella delle partizioni. Ma...
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
File system perfettamente valido, dopo una risincronizzazione. Quindi va bene; controlliamo sui nostri file di dati:
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
Solido - nessuna corruzione dei dati! Ma questo ha le stesse identiche impostazioni, quindi nulla è stato mappato in modo diverso tra i due gruppi RAID. Lasciamo cadere questa cosa prima di provare a romperla.
root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
Fare un passo indietro
Prima di provare a rompere questo, parliamo del perché è difficile da rompere. RAID 5 funziona utilizzando un blocco di parità che protegge un'area della stessa dimensione del blocco su ogni altro disco dell'array. La parità non è solo su un disco specifico, ma viene ruotata uniformemente attorno ai dischi per distribuire meglio il carico di lettura sui dischi durante il normale funzionamento.
L'operazione XOR per calcolare la parità è simile alla seguente:
DISK1 DISK2 DISK3 DISK4 PARITY
1 0 1 1 = 1
0 0 1 1 = 0
1 1 1 1 = 0
Quindi, la parità viene distribuita tra i dischi.
DISK1 DISK2 DISK3 DISK4 DISK5
DATA DATA DATA DATA PARITY
PARITY DATA DATA DATA DATA
DATA PARITY DATA DATA DATA
Una risincronizzazione viene in genere eseguita quando si sostituisce un disco guasto o mancante; viene anche fatto mdadm createper assicurare che i dati sui dischi siano allineati con l'aspetto della geometria del RAID. In tal caso, l'ultimo disco nelle specifiche dell'array è quello "sincronizzato": tutti i dati esistenti sugli altri dischi vengono utilizzati per la sincronizzazione.
Quindi, tutti i dati sul "nuovo" disco vengono cancellati e ricostruiti; o costruendo nuovi blocchi di dati dai blocchi di parità per quello che avrebbe dovuto essere lì, oppure costruendo nuovi blocchi di parità.
La cosa interessante è che la procedura per entrambe queste cose è esattamente la stessa: un'operazione XOR attraverso i dati dal resto dei dischi. Il processo di risincronizzazione in questo caso potrebbe avere nel suo layout che un determinato blocco dovrebbe essere un blocco di parità e pensare che stia costruendo un nuovo blocco di parità, quando in realtà sta ricreando un vecchio blocco di dati. Quindi, anche se pensa che sta costruendo questo:
DISK1 DISK2 DISK3 DISK4 DISK5
PARITY DATA DATA DATA DATA
DATA PARITY DATA DATA DATA
DATA DATA PARITY DATA DATA
... potrebbe essere solo la ricostruzione DISK5dal layout sopra.
Pertanto, è possibile che i dati rimangano coerenti anche se l'array è stato creato in modo errato.
Lanciare una scimmia nelle opere
(non una chiave inglese; l'intera scimmia)
Test 1:
Facciamo l'array nell'ordine sbagliato! sdc, quindi sdd, quindi 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, va tutto bene. Abbiamo un filesystem?
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>
No! Perché? Perché mentre i dati sono tutti lì, è nell'ordine sbagliato; quello che una volta era 512 KB di A, quindi 512 KB di B, A, B e così via, ora è stato mischiato in B, A, B, A. Il disco ora sembra incoerente per il controllo del filesystem, non funzionerà. L'output di mdadm --misc -D /dev/md1ci fornisce maggiori dettagli; Sembra così:
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
Quando dovrebbe apparire così:
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
Quindi, va tutto bene. Questa volta abbiamo sovrascritto un sacco di blocchi di dati con nuovi blocchi di parità. Ricrea, con il giusto ordine ora:
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
Bene, c'è ancora un filesystem lì! Hai ancora dati?
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
Successo!
Test 2
Ok, cambiamo le dimensioni del pezzo e vediamo se questo ci dà un po 'di rottura.
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>
Sì, sì, viene installato quando impostato in questo modo. Ma possiamo recuperare?
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
Di nuovo successo!
Test 3
Questo è quello che pensavo avrebbe ucciso sicuramente i dati: facciamo un algoritmo di layout diverso!
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).
Spaventoso e cattivo - pensa di aver trovato qualcosa e vuole fare qualche aggiustamento! Ctrl+ C!
Clear<y>? cancelled!
fsck.ext4: Illegal inode number while checking ext3 journal for /dev/md1
Ok, crisi evitata. Vediamo se i dati sono ancora intatti dopo la risincronizzazione con il layout errato:
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
Successo!
Test 4
Dimostriamo anche che l'azzeramento del superblocco non è dannoso molto velocemente:
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
Sì, non è un grosso problema.
Test 5
Lanciamo tutto quello che abbiamo. Tutti e 4 i test precedenti, combinati.
- Ordine del dispositivo errato
- Dimensione del pezzo sbagliata
- Algoritmo di layout errato
- Superblocchi azzerati (lo faremo tra le due creazioni)
Onward!
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
Il verdetto?
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
Wow.
Quindi, sembra che nessuna di queste azioni abbia danneggiato i dati in alcun modo. Sono stato abbastanza sorpreso da questo risultato, francamente; Mi aspettavo una moderata probabilità di perdita di dati sulla modifica della dimensione del blocco e una certa perdita sulla modifica del layout. Ho imparato qualcosa oggi.
Quindi .. Come posso ottenere i miei dati ??
Tutte le informazioni che hai sul vecchio sistema ti sarebbero estremamente utili. Se conosci il tipo di filesystem, se hai delle tue vecchie copie /proc/mdstatcon informazioni su ordine dell'unità, algoritmo, dimensione del blocco e versione dei metadati. Hai impostato gli avvisi e-mail di mdadm? In tal caso, trovane uno vecchio; in caso contrario, controllare /var/spool/mail/root. Controlla ~/.bash_historyper vedere se la tua build originale è lì.
Quindi, l'elenco delle cose che dovresti fare:
- Eseguire il backup dei dischi con
ddprima di fare qualsiasi cosa !!
- Prova
fsckl'attuale md attivo: potresti esserti appena imbattuto nello stesso ordine di prima. Se conosci il tipo di filesystem, è utile; usa quello fsckstrumento specifico . Se uno qualsiasi degli strumenti offre di riparare qualcosa, non lasciarlo a meno che tu non sia sicuro di aver effettivamente trovato il filesystem valido! Se si fsckoffre di risolvere qualcosa per te, non esitare a lasciare un commento per chiedere se sta effettivamente aiutando o sta semplicemente per eseguire il nuke dei dati.
- Prova a costruire l'array con parametri diversi. Se hai un vecchio
/proc/mdstat, allora puoi semplicemente imitare ciò che mostra; in caso contrario, allora sei un po 'al buio: provare tutti i diversi ordini di unità è ragionevole, ma controllare ogni possibile dimensione del blocco con ogni possibile ordine è inutile. Per ognuno, fsckper vedere se ottieni qualcosa di promettente.
Quindi è quello. Scusate il romanzo, sentitevi liberi di lasciare un commento se avete domande e buona fortuna!
nota a piè di pagina: meno di 22 mila caratteri; 8k + timido del limite di lunghezza