Migliorerebbe le prestazioni di scrittura per riempire un'unità riformattata con zeri?


14

Ho un disco da 2 TB che è stato riempito fino a> 99%. Ho eliminato le partizioni con fidske le ho formattate con mkfs.ext4.

Per quanto ne so, i dati effettivi presenti sull'unità esistono ancora. Tuttavia la tabella delle partizioni è stata riassegnata.

La domanda è: migliorerebbe le prestazioni di scrittura per ulteriori azioni di scrittura se il disco venisse pulito ? Con pulito intendo riempire il disco con zeri?

Qualcosa di simile a

dd if=/dev/zero of=/dev/sdx bs=1 count=4503599627370496

8
Non c'è vantaggio di avere zero per cominciare poiché sovrascriverà tutto ciò che è lì per cominciare.
Moab,

7
Se fosse un SSD, la risposta sarebbe "no no", perché mkfs.ext4 in realtà usa TRIM per scartare l'intero contenuto della partizione, quindi scrivere manualmente zeri sopra ciò ridurrebbe leggermente le prestazioni.
user1686

2
@grawity Mi sono chiesto se esiste un SSD che trasforma automaticamente le scritture di tutti gli zeri in TRIM.
Kasperd,

@kasperd: buona domanda di follow-up!
liori,

Un'altra possibile domanda di follow-up: se detto disco fosse una VM montata su una SAN che eseguiva la deplication del disco di basso livello, ciò potrebbe essere d'aiuto (in questo caso se i dati che erano stati eliminati a livello di VM, a meno che il sistema non utilizzi qualche API compatibile con VM , vedrebbe alla SAN che tutti quei blocchi eliminati devono rimanere attaccati, mentre impostarli su tutti gli zeri finirebbe con un mucchio di blocchi duplicati tutti puntati su una cosa tutto zero)
Foon,

Risposte:


36

No, non migliorerebbe le prestazioni.

TL; DR: i dischi rigidi magnetici rotazionali non funzionano in questo modo.

Innanzitutto, quando si scrivono dati su un'unità di memorizzazione magnetica rotazionale, tali dati vengono trasformati in domini magnetici che potrebbero effettivamente apparire molto diversi dal modello di bit che si sta scrivendo. Ciò è dovuto in parte al fatto che è molto più semplice mantenere la sincronizzazione quando il modello letto dal piatto presenta una certa variabilità e, ad esempio, una lunga stringa di valori "zero" o "uno" renderebbe molto difficile mantenere la sincronizzazione . (Hai letto 26.393 bit o 26.394 bit? Come riconosci il confine tra bit?) Le tecniche per eseguire questa trasformazione tra bit di dati del computer e blocchi memorizzabili si sono evolute nel tempo; ad esempio, cerca Modulazione di frequenza modificata , MMFM,Registrazione di codici di gruppo e la tecnologia più generale delle codifiche limitate della durata .

Il processo di registrazione vero e proprio, come HAMR , PMR , a strati e così via, è ortogonale a ciò in quanto descrivono la meccanica di come i domini magnetici sono memorizzati sul supporto fisico.

In secondo luogo, quando si scrivono nuovi dati in un settore, i domini magnetici delle parti pertinenti del piatto vengono semplicemente impostati sul valore desiderato. Questo viene fatto indipendentemente dal dominio magnetico precedente in quella particolare posizione fisica. Il piatto gira già sotto la testina di scrittura; prima leggere il valore corrente, quindi scrivere il nuovo valore se e solo se diverso, farebbe sì che ogni scrittura richiedesse due rivoluzioni (o una testa in più per ogni piatto), causando una latenza di scrittura doppia o aumentando notevolmente la complessità dell'unità, a sua volta aumentando i costi. Poiché il fattore limitante nelle prestazioni I / O sequenziali del disco rigido è la velocità con cui ciascun bit passa sotto la testina di lettura / scrittura, ciò non offrirebbe alcun vantaggio all'utente. (A parte, il fattore limitante nelle prestazioni I / O casuali è la velocità con cui la testina di lettura / scrittura può essere posizionata sul cilindro desiderato e quindi il settore desiderato arriva sotto la testina. Il motivo principale per cui gli SSD possono essere così veloci nei carichi di lavoro I / O casuali è che eliminano completamente entrambi questi fattori.)

Come sottolineato da JakeGould , uno dei motivi per cui potresti voler sovrascrivere l'unità con un modello fisso (come tutti gli zeri) sarebbe quello di garantire che nessun residuo di dati precedentemente memorizzati possa essere recuperato , deliberatamente o accidentalmente. Ma farlo non avrà alcun effetto sulle prestazioni dell'unità in futuro, per i motivi sopra indicati. Un altro motivo, che si potrebbe presumibilmente dire "migliorare le prestazioni", come sottolineato da liori , è quello di aiutare la compressione di porzioni inutilizzate di immagini del disco memorizzate, ma anche ciò non migliora le prestazioni del sistema in uso.


3
Un altro motivo per l'azzeramento di partizioni / unità è se si prevede di eseguire il dump di partizioni / unità non elaborate (ad esempio come backup, creazione di un'immagine del sistema operativo per più macchine, come tecnica di migrazione del sistema, ecc.). Gli zeri si comprimono bene, il che potrebbe essere diverso da qualsiasi contenuto precedente memorizzato sul disco.
liori,

@liori Un buon punto, ma questo non è uno scenario comune per l'utente finale ed è abbastanza lontano da ciò che l'OP sta descrivendo.
un CVn

Quindi i dischi ottici sono o non rotazionali o magnetici?
Max Ried il

4

Dici questo:

La domanda è: migliorerebbe le prestazioni di scrittura per ulteriori azioni di scrittura se il disco venisse pulito? Con pulito intendo riempire il disco con zeri?

100% no. La scrittura di zeri su un disco non migliora le prestazioni. Lo faresti solo per distruggere i dati. Quindi sapendolo, dici questo:

Per quanto ne so, i dati effettivi presenti sull'unità esistono ancora.

Tecnicamente sì ... I dati che esistevano in precedenza sull'unità esistono ancora sull'unità a un livello fondamentale. Detto questo, non esiste in una forma che sia facilmente accessibile o recuperabile a questo punto, ma potrebbe essere una preoccupazione se sei veramente preoccupato che i dati vengano compromessi da qualcuno disposto a fare lo sforzo di recuperare quei frammenti di dati che rimangono.

Quindi, se la sicurezza e la privacy sono una preoccupazione, allora potresti voler scrivere zeri sull'unità per assicurarti che tutto lo spazio libero sia veramente cancellato. Ma la sicurezza e la privacy sono l'unico motivo assoluto per cui potresti mai cancellare lo spazio libero con zeri poiché fare qualcosa del genere non migliora mai le prestazioni.


Eseguire uno strumento del genere recovernon è considerato "facile"? Avrebbe generato un sacco di file su un disco completo che era appena stato mkfs.
Hobbs,

0

Il mio regalo da due centesimi per tutti voi è la mia esperienza, SÌ aiuta ma con cautela.

Avevo molti SSD e in base ai miei test mi raccomando di riempire completamente con zeri prima di riscrivere la tabella principale e invece di eliminare le partizioni, ricreare la tabella principale.

Più avanti spiegherò perché, ma i passaggi sarebbero ˋddˋ per riempire l'intero SSD, usare bs = 1M, molto più veloce di bs = 1 e dimenticherò il parametro count per farlo andare fino alla fine (darebbe l'errore di non più spazio quando raggiungere la fine, che viene individuato, quindi non preoccuparti di vedere un tale errore, deve essere mostrato); dopo il riempimento completo usa gparted o qualunque cosa tu voglia scrivere una tabella principale (MBR / GPT / etc) secondo necessità, questo "taglierà" tutto il disco, quindi creerà partizioni con il formato desiderato, ecc.

Perché riempirlo di zeri? La risposta breve è che la mia esperienza è quando la riempio di zeri alcuni SSD che dove sono stati riparati dando 2-24 blocchi illeggibili, non più blocchi irreali.

Ora la prima cosa che faccio quando ricevo un nuovo SSD, prima di usarlo, è riempirlo completamente di zeri, per assicurarmi di non subire nuovamente i comuni errori casuali di blocchi illeggibili da 1 KiB.

La mia esperienza: utilizzo del software per leggere / testare l'intero SSD (ti dice quanto tempo impiega a leggere ogni 'settore') Stavo ottenendo un sacco di coppie di "settari da 512 byte" (blocchi da 1 KiB) che non sono raggiungibili e la loro posizione cambia in modo casuale e il numero di guasti varia da 2 a 24, ecc .; dopo il riempimento completo con zero e ricreare la tabella principale (che va in assetto) non più settori illeggibili.

Il mio crash test: Instesd di riempire di zeri per recuperare da tali errori, ho lasciato un SSD da utilizzare, dopo poche ore e con solo meno di un terabyte scritto (SSD 120GiB) è morto missibilmente, non consente alcun accedervi più, il BIOS della scheda madre non può vederlo, le custodie USB si bloccano quando si accede ad esso, quindi né Windows lo vede, né Linix fdisk lo vede.

È stato un test "die" con più SSD che avevo acquistato contemporaneamente, quelli identici ... tutto ciò che non ho azzerato è morto, il resto ha molti blocchi riallocati, ma senza errori illeggibili.

Naturalmente, la mia conclusione è che tutti gli SSD non sono affidabili, indipendentemente dal marchio e dalla capacità.

Quindi, per prima cosa, con loro, nella mia esperienza, è costringerli a riempirsi completamente almeno una volta, meglio con zeri che con casuale (è più veloce).

Inoltre, la maggior parte degli SSD esegue il trim interno quando viene scritta con zeri (algoritmi di raccolta dei garbe, ecc.).

Inoltre, se li riempi per la prima volta, tutti i blocchi che danno errori di scrittura vengono riallocati. È molto meglio che ciò accada senza dati vitali, quando si scrivono zeri se i dati si perdono (tutti erano zeri) non è rilevante, ma se i dati sono "vitali" per il sistema operativo è molto male.

La maggior parte degli SSD riallocati lo fa ma perdendo i dati sul blocco che ha dato l'errore di scrittura, solo "enterprise" (costano> 10 € per GiB) riprova a scrivere dopo aver riallocato correttamente. Alcuni SSD perderanno anche tutti gli altri "settori" su tale blocco fallito (come fare un "scarto").

Quindi, provalo prima, dopo il riempimento completo, controlla i dati SMART per vedere quante riallocazioni possono ancora essere fatte.

Non è così importante quante riallocazioni siano state fatte, la maggior parte degli SSD provengono da manufacter con alcuni blocchi già riallocati, trovare uno con zero è inferiore all'1%, quindi l'importante è il rapporto, riallocare rispetto alle future riallocazioni possibili.

È la mia esperienza dopo la morte di centinaia di SSD nell'arco di 5 cinque anni, alcuni sono morti nella prima ora di utilizzo, altri in una settimana, altri in un mese; ma tutto ciò che avevo fatto era stato riempito completamente per zero per 2 o 3 anni, con un 13GiB scritto ogni giorno, 3 * 365 * 13 GiB = 13,9TB scritti, molto meno di quanto affermano le fabbriche (> 100TiB).

Ma la velocità è importante, soprattutto se su Windows (su Linux un buon striping LVM2 2xHDD offre gli stessi tempi di avvio ma non falliscono in> 25 anni), quindi usare SSD con un prezzo di 0,21 € per Gigabyte (120GiB = 25 €) è ne vale la pena (per Windows), tra cui devono essere cambiati dopo 2 o 3 anni; spero che la tecnologia migliorerà l'affidabilità.

Per Linux non voglio più SSD fino a quando non saranno più affidabili, ma per Windows (Vista, 7 e 10) la partizione di sistema è un must (tempi di avvio dieci volte inferiori in alcuni casi, con Windows Vista, invece di> 30min avviarlo si avvia> 4min sul mio vecchio laptop).

Sì, il riempimento completo con zero è un must, data la mia esperienza.

Ma, solo quando ricevi l'SSD e prima di usarlo per qualsiasi cosa.

Suggerimento: se SSD non esegue correttamente la garbage collection e il sistema operativo non dice di tagliare tutto, meglio fare un riempimento completo con zeri, alla fine questo è ciò che è internamente nell'SSD quando elimina i blocchi. Anche la scrittura di zeri cancella l'elettronica, ecco perché aiuta a recuperare blocchi di lettura non riusciti.

Inoltre, ogni volta che si modificano i dati su di esso, provare a fare un clone, l'SSD informerà che la scrittura era OK, anche su settori illeggibili (possono essere scritti OK ma non letti), nessun sistema operativo è progettato per supportare tale condizione , tutti si applicano se wtite è OK i dati possono essere letti; non confondere leggibile con dati diversi letti attraverso ciò che è stato scritto.

Questa è la mia esperienza con SSD e HDD. Per l'avvio e le app di Windows utilizzo SSD, ma sempre con un clone eseguito su normali HDD poiché SSD muore in meno di 3 anni, ma per Linux uso 2 o 3 x buoni HDD da 2,5 "per ottenere tempi simili sull'uso normale come quello che SSD darebbe , ma dura molto più a lungo (> 25 anni).

Non sono disposto a pagare> 1000 € per SSD da 100GiB che funziona bene per 10 anni, preferisco pagare 25 € per 130GiB ogni 2 o 3 anni. Il prezzo conta 100 € all'anno (impresa) contro 10 € all'anno (Yucon, Samsung, ecc.), Basta fare i conti.


Costringere a scrivere su settori danneggiati è davvero un modo abbastanza affidabile per "risolverli", purché siano ancora disponibili settori riservati.
coriandoli
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.