Cum să suprascrieți un hard disk foarte mare (18 TB) cu date aleatorii folosind comenzi shell în Linux

Aș dori să suprascriu un hard disk foarte mare (18 TB) cu octeți aleatori, pentru a verifica apoi datele inteligente pentru sectoare realocate sau alte erori.

Deoarece badblocks are unele limitări în ceea ce privește numărul de blocuri cu care va funcționa într-o singură rulare, am încercat „metoda cryptsetup” descrisă pe wiki archlinux:

https://wiki.archlinux.org/title/Badblocks#Finding_bad_sectors

Am configurat un câmp de dispozitiv logic criptat pe întreaga unitate și apoi am folosit comanda „shred” pentru a scrie zerouri pe dispozitivul deschis:

cryptsetup deschide /dev/device eld --type plain --cipher aes-xts-plain64
shred -v -n 0 -z /dev/mapper/eld

A continuat să imprime linii precum

shred: /dev/mapper/eld: trece 1/1 (000000)...870MiB/17TiB 0%
shred: /dev/mapper/eld: trece 1/1 (000000)...1.7GiB/17TiB 0%
...
shred: /dev/mapper/eld: trece 1/1 (000000)...4.1TiB/17TiB 24%

dar apoi s-a oprit la 4.1TiB/17TiB scris. Am verificat acest lucru cu hexdump, zerourile nu au fost scrise dincolo de adresa octetului 0x428249b0000 (4570459340800 ~ 4,156 TiB):

hexdump -C --skip 0x428249a0000 /dev/mapper/eld | cap
428249a0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
428249b0000 b3 cd d0 34 72 15 f2 2c f6 32 90 fb 69 24 1f ec |...4r..,.2..i$..|
428249b0010 a0 f4 88 a5 56 e7 13 82 94 e5 e0 f5 37 da c3 59 |....V.......7..Y|
428249b0020 9b 55 9f d8 39 a1 41 dc 52 ca 7b 3a 95 f5 59 e2 |.U..9.A.R.{:..Y.|

Multe comenzi standard par să aibă probleme cu discurile de mare capacitate, deoarece numerele implicate sunt prea mari pentru tipurile de date pe 32 de biți.Ce instrumente de citire/scriere pe Linux sunt capabile să citească/scrie dincolo de aceste limite imaginare de 2TiB, 4TiB în mod fiabil?

Editare: Actualizat conform comentariului

Aș folosi pur și simplu

dd if=/dev/urandom of=/dev/sdX bs=1M status=progress iflag=fullblock oflag=fullblock

Aici /dev/sdX este dispozitivul pentru hard disk.

În loc de cryptsetup + shred, am folosit cryptsetup + pv (și cat ar trebui să funcționeze în loc de pv, dar nu ar oferi informații despre progres) și am indicat stdin către /dev/zero:

cryptsetup deschide /dev/device eld --type plain --cipher aes-xts-plain64
</dev/zero pv ></dev/mapper/eld

Acest lucru are avantajul (în comparație cu dd) că nu trebuie specificate argumente obscure și performanța pe o legătură SATA 3.3 6Gb/s este bună (>200MiB/s).

pv încă a eșuat când a fost atins finalul, dar am verificat că totuși a suprascris întregul dispozitiv logic cu zerouri. Ceea ce înseamnă că dm-crypt a suprascris întregul hard disk cu octeți pseudo-aleatori.

Acum erorile de hard disk pot fi verificate în cel puțin două moduri:

1.Se caută date SMART degradate (cum ar fi sectoarele realocate) în rezultatul

smartctl -a /dev/device

2.Citirea datelor din /dev/mapper/eld și verificarea faptului că toți octeții citiți au valoarea zero. Rularea comenzii cmp de la diffutils pentru a face această comparație:

cmp -l -b /dev/zero /dev/mapper/eld

Fie va tipări adresa de octeți a primei nepotriviri și va ieși cu eroare, fie nu va găsi nicio nepotrivire și apoi va tipări „cmp EOF pe /dev/mapper/eld...” (și va ieși în continuare cu eroare).

Nepotrivirea înseamnă că fie un hard disk are o eroare permanentă de înregistrare în acea poziție, fie poate fi o eroare aleatorie care nu se va repeta exact în aceeași poziție.

La prima rulare a cmp, într-adevăr, am primit o eroare deja după 8 secunde, ceea ce am fost foarte surprins să văd. Datele SMART nu au arătat nicio degradare, iar syslog nu a dezvăluit niciun mesaj de eroare privind hard disk-ul.

Apoi am încercat să rulez din nou comanda cmp pentru a verifica dacă eroarea de înregistrare este reală, dar nepotrivirea la acea poziție nu a mai apărut. A fost o eroare aleatorie în întregul proces de citire+evaluare. Deci, nu vă bazați pe o singură rulare a comenzii cmp; în cazul în care se găsește o nepotrivire, rulați-l din nou. Dacă eroarea dispare, ignorați prima nepotrivire sau poate încercați din nou. Dacă eroarea persistă, returnați hard disk-ul vânzătorului, deoarece cel mai probabil este defect și degradarea sa în timp poate fi mai rapidă în comparație cu un hard disk sănătos.

.