Toshiba

I dischi SMR alla prova: testiamo il Toshiba P300 da 6 TB

di pubblicato il nel canale Device I dischi SMR alla prova: testiamo il Toshiba P300 da 6 TB

All'inizio del 2020 c'è stato parecchio clamore nel mondo degli hard disk: si è scoperto che tutti i principal produttori avevano utilizzato la tecnologia SMR senza dichiararlo. Ma quanto incide questa tecnologia sulle prestazioni? Abbiamo provato un disco Toshiba P300 da 6 TB per verificare quali siano i suoi punti di forza e di debolezza nell'uso da parte di utenza "normale"

 

Da qualche tempo i produttori di hard disk hanno cominciato a vendere modelli che adottano la tecnologia SMR, o shingled magnetic recording (registrazione magnetica a tegole). Tale tecnologia è stata al centro di un forte dibattito nel corso degli scorsi mesi, quando si è scoperto che tutti i principali produttori hanno inserito nel proprio listino modelli che la sfruttavano senza, però, dichiararlo. Le proteste sono state causate dal fatto che, per via del funzionamento stesso della tecnica SMR, ci sono alcune differenze prestazionali rispetto ai dischi tradizionali. Per verificare quanto queste impattino sull'impiego in un PC desktop abbiamo testato un disco Toshiba P300 da 6 TB di capienza, mettendolo alla prova in differenti scenari d'uso.

Dischi SMR: come e perché sono differenti

Toshiba P300

Abbiamo già dato una visione d'insieme del funzionamento della tecnologia SMR nel seguente articolo: Hard disk SMR: Western Digital, Seagate e Toshiba mancano di trasparenza. Riprendendo i concetti espressi in tale articolo, la tecnologia SMR dispone le tracce in maniera differente rispetto ai dischi tradizionali: dal momento che le testine di lettura sono più piccole di quelle di scrittura, l'idea di base è quella di sovrapporre parte delle tracce in maniera tale da mantenere intatta la capacità delle testine di leggere i dati, ottenendo però una maggiore densità.

Questo approccio porta teoricamente a produrre hard disk più capienti, o hard disk con meno piatti rotanti (e quindi più longevi) e più economici (perché per ottenere la stessa capacità servono meno piatti).

L'aspetto negativo sta nella necessità di riscrivere tutto un settore (solitamente di 256 MB) quando se ne modifica un pezzo: la disposizione a tegole delle tracce fa sì che la riscrittura anche di un singolo blocco di 4 kB vada a intaccare la traccia adiacente, per cui è necessario riscrivere l'intero settore perché tutte le tracce siano scritte correttamente. Ciò porta a cali prestazionali anche significativi nel momento in cui è necessario riscrivere diversi blocchi.

Toshiba P300 6 TB SMR alla prova

I test sono stati effettuati su un sistema dotato di processore AMD Ryzen 5 3600, scheda madre MSI B450 Mortar Titanium, 16 GB di RAM operante a 3.200 MHz e scheda video Powercolor Radeon RX 5700 Red Devil con 8 GB di memoria video. Erano installati sia Windows 10 2004 che Linux (KDE neon, su base Ubuntu 18.04).

Abbiamo messo alla prova il disco in vari scenari. Questi i test che abbiamo effettuato:

  • CrystalDiskMark 7.0.0 x64, Windows 10
  • copia di file, Windows 10
  • fio, con carichi che simulano CrystalDiskMark, Linux
  • dd, Linux (usando il comando dd bs=256M count=1000 if=/dev/zero of=/mnt/)

In tutti questi test si evidenzia come le prestazioni del disco non siano costanti. In particolare con il test eseguito tramite dd su Linux, che porta a scritture sequenziali, emerge come la gestione della cache faccia una differenza sostanziale.

In CrystalDiskMark si può vedere come la lettura sia relativamente contenuta in termini di velocità, arrivando a 150 MB/s: questo si spiega guardando al regime di rotazione dei piatti, che arrivano a 5.400 rpm. In quest'ottica i valori di lettura appaiono sensati e commisurati alle aspettative. Diverso, invece, è il discorso riguardo le scritture: sia quelle sequenziali che soprattutto quelle casuali sono molto più veloci di quanto atteso.

Questi risultati sono confermati anche dai test sotto Linux con il comando fio, sebbene con valori assoluti differenti a causa dei diversi file system. La spiegazione che è possibile dare è che in questi casi intervenga la cache da 256 MB: il suo utilizzo fa sì che le prestazioni siano effettivamente migliori rispetto ai dischi tradizionali, dotati di cache più piccole.

La cache ha, però, dei limiti nella sua capacità di supplire ai deficit intrinseci della tecnologia SMR. Il motivo per cui abbiamo eseguito dei test con ddsu Linux è che è possibile eseguire scritture sequenziali specificando la dimensione dei blocchi che vengono scritti: in questo modo si può specificare una dimensione del blocco che vada a saturare completamente la cache, esponendone eventuali limiti.

Il risultato è che il disco si comporta bene, ma incespica ogni tanto. In momenti apparentemente casuali il disco subisce infatti rallentamenti significativi. Abbiamo riscontrato cali degni di nota nelle prestazioni di scrittura sequenziale: il comando dd ha dato in due occasioni come risultato una media di 79,7 MB/s di velocità per la copia di 100 GB di dati. Per avere un metro di confronto abbiamo eseguito lo stesso test su un disco Toshiba P300 da 2 TB con tecnologia CMR e il risultato è stato nell'ordine dei 155 MB/s, ovvero quasi il doppio.

La spiegazione di questo comportamento sta probabilmente nella necessità del firmware di effettuare delle operazioni di garbage collection di quando in quando per ottimizzare le prestazioni del disco. Tali operazioni, però, vengono eseguite dal disco senza considerare eventuali altre attività in corso, fatto che rallenta anche notevolmente le prestazioni. L'impossibilità di prevedere quando ciò possa accadere rende i dischi SMR meno affidabili di quelli CMR da un punto di vista prestazionale.

La copia di file procede senza particolari intoppi, con prestazioni che potremmo definire nella media per i dischi a piatti rotanti. La copia di circa 100 GB di dati è proseguita con una velocità media di circa 100 MB/s, con scostamenti poco significativi su entrambi i lati di questo valore. Nell'uso per l'archiviazione di file, dunque, non si notano significative differenze rispetto ai dischi CMR.

Dischi SMR: ne vale la pena?

Discutendo dell'argomento in redazione è emerso un certo consenso sul fatto che gli hard disk siano ormai un oggetto che è diventato una commodity, una scatola nera la cui unica caratteristica importante per molti è il numero di terabyte della capienza. Proprio per questo i produttori sono riusciti a far passare per diverso tempo i dischi SMR per dischi normali: perché il ciclo di sviluppo dell'hard disk come tecnologia sta avvicinandosi alla sua conclusione e ha raggiunto ormai un livello tale per cui anche differenze minori nelle prestazioni non si fanno notare poi molto.

Le nostre prove mostrano che per l'utilizzatore medio non ci sono particolari differenze nell'impiego dei dischi SMR. Si notano alcuni cambiamenti solo per alcuni carichi specifici e per situazioni circoscritte. Con gli SSD che crescono di dimensioni e diventano più economici, gli hard disk tradizionali a piatti rotanti sono sempre più relegati al ruolo di sola archiviazione di dati, per il quale non servono prestazioni particolarmente elevate né in lettura né in scrittura. Il dato più rilevante diventa quello della capacità totale, che è poi quello che più interessa a molti.

In questo scenario, che al momento appare quello più diffuso, i dischi SMR come questo Toshiba P300 da 6 TB diventano un'alternativa papabile ai dischi CMR perché offrono prestazioni sufficienti per tutti i principali casi d'uso. Resta però evidente come i dischi SMR abbiano limitazioni anche forti per quegli scenari più specifici in cui sono necessarie prestazioni maggiori e/o più costanti. In tali casi continua a essere necessario avvalersi di dischi CMR, che mettono sul piatto caratteristiche indubbiamente più interessanti.

Discorso a parte merita il mondo server e NAS, per il quale i dischi SMR gestiti dal firmware del disco sono assolutamente inadatti per via proprio dell'incostanza delle prestazioni. L'unico produttore ad aver proposto dischi SMR in questo mercato è Western Digital, che ha incontrato per questo una fortissima protesta da parte dell'utenza (sfociata anche in una class action negli Stati Uniti). I dischi SMR possono essere utilizzati senza particolari problemi nella maggior parte degli scenari di archiviazione nel mondo desktop, ma appare chiaro che questo sia il confine della loro utilità. Al di fuori di questo, la tecnologia SMR mostra tutti i suoi limiti.

27 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
giovanni6914 Settembre 2020, 15:44 #1

Un grosso "ma"....

"[I]Il risultato è che il disco si comporta bene, ma incespica ogni tanto. In momenti apparentemente casuali il disco subisce infatti rallentamenti significativi. Abbiamo riscontrato cali degni di nota nelle prestazioni di scrittura sequenziale: il comando dd ha dato in due occasioni come risultato una media di 79,7 MB/s di velocità per la copia di 100 GB di dati. Per avere un metro di confronto abbiamo eseguito lo stesso test su un disco Toshiba P300 da 2 TB con tecnologia CMR e il risultato è stato nell'ordine dei 155 MB/s, ovvero quasi il doppio.[/I]"

Se anche per l'utenza normale (non NAS), causa impuntamenti casuali, la media è quasi pari alla metà dei 155 MB/s di un CMR, ovvero 79.7, come si fa a dire che si comporta bene?

E quella media nasconde quindi picchi molto più bassi di quegli 80 MB/s... roba da HDD IDE....

E' un mah con tanti puntini....
Cfranco14 Settembre 2020, 15:55 #2
Originariamente inviato da: giovanni69
"[I]Il risultato è che il disco si comporta bene, ma incespica ogni tanto. In momenti apparentemente casuali il disco subisce infatti rallentamenti significativi. Abbiamo riscontrato cali degni di nota nelle prestazioni di scrittura sequenziale: il comando dd ha dato in due occasioni come risultato una media di 79,7 MB/s di velocità per la copia di 100 GB di dati. Per avere un metro di confronto abbiamo eseguito lo stesso test su un disco Toshiba P300 da 2 TB con tecnologia CMR e il risultato è stato nell'ordine dei 155 MB/s, ovvero quasi il doppio.[/I]"

Se anche per l'utenza normale (non NAS), causa impuntamenti casuali, la media è quasi pari alla metà dei 155 MB/s di un CMR, ovvero 79.7, come si fa a dire che si comporta bene?

E quella media nasconde quindi picchi molto più bassi di quegli 80 MB/s... roba da HDD IDE....

E' un mah con tanti puntini....


Per un utilizzo di archiviazione casalinga la velocità in scrittura non è così importante, normalmente il 99% del tempo il disco serve solo in lettura, e per piccoli file la cache nasconde bene le problematiche, anche se si prende una pausa ogni tanto sul PC di casa non è un problema.

I problemi sono negli ambiti dove ci sono scritture continue e quindi sono richieste performance continuative, oltre ai NAS ad esempio in un apparato di videosorveglianza un disco SMR lo vedo molto male, in generale su server di qualsiasi tipo io eviterei quei dischi.
Slater9114 Settembre 2020, 15:56 #3
Originariamente inviato da: giovanni69
Se anche per l'utenza normale (non NAS), causa impuntamenti casuali, la media è quasi pari alla metà dei 155 MB/s di un CMR, ovvero 79.7, come si fa a dire che si comporta bene?

E quella media nasconde quindi picchi molto più bassi di quegli 80 MB/s... roba da HDD IDE....

E' un mah con tanti puntini....


Semplice: come detto, si tratta di un caso limite. I numeri vanno visti nel contesto, non fuori da esso, e in questo caso il contesto è chiaro: è stato fatto un test appositamente costruito per mettere in difficoltà il disco e in due occasioni (su 5) c'è stato un rallentamento. Il test non è rappresentativo dell'utilizzo "normale" di un disco. Se poi vogliamo leggere quel dato ignorando tutto il resto del pezzo è un altro conto.
Quindi confermo quanto scritto: il disco si comporta mediamente bene, anche se ci sono intoppi casuali. Non è un disco per situazioni che richiedono alte prestazioni, come ho scritto.
giovanni6914 Settembre 2020, 16:09 #4
Grazie per il chiarimento. Il test evidenzia che "la cache ha, però, dei limiti nella sua capacità di supplire ai deficit intrinseci della tecnologia SMR" , similmente ad un SSD privo di cache (es. il noto decadimento del Crucial BX) rispetto a quelli che ne sono forniti . Non si nota tranne quando si iniziano trasferimenti di dimensione sostanziosa.

Avete scritto che l'utilizzo di Linux è stato adottato per facilitare il test, per renderlo possibile agilmente. " in questo modo si può specificare una dimensione del blocco che vada a saturare completamente la cache, esponendone eventuali limiti."
[S]Questo non vuol dire che quanto avete testato non debba trovare riscontro anche nel mondo reale: basta copiare/incollare ripetutamente files che superano quei 256MB, no?[/S]
"Il test non è rappresentativo dell'utilizzo "normale" di un disco. "
[S] Si mette in difficoltà non rappresentativa un disco copiando blocchi superiore alla cache da 256MB? Non mi pare un'operazione così estrema, anzi per me è piuttosto rappresentativa nel caso di scritture di file di media dimensione (es segmenti di immagine di backup).[/S]

E " Tali operazioni [garbage collection], però, vengono eseguite dal disco senza considerare eventuali altre attività in corso". Se questo vi sembra normale... ok.

E non possiamo che ringraziarvi per aver evidenziato i punti deboli.

Originariamente inviato da: Cfranco
Per un utilizzo di archiviazione casalinga la velocità in scrittura non è così importante, normalmente il 99% del tempo il disco serve solo in lettura [...].


Veramente anche in ambito casalingo si può aver necessità di effettuare backup, operazione squisitamente in scrittura, nel caso in cui venisse utilizzato questo SMR come destinazione.

Originariamente inviato da: mally
beh se la coerenza dei dati non è a rischio e il prezzo fosse 30/40% inferiore ad un disco tradizionale si potrebbe farci un pensiero...

Vediamo se il risparmio di costi si traduce in margini per il produttore o quanto auspichi.
Cfranco14 Settembre 2020, 16:27 #5
Originariamente inviato da: giovanni69
Veramente anche in ambito casalingo si può aver necessità di effettuare backup che sono operazioni squisitamente in scrittura, nel caso in cui venga utilizzato questo SMR come destinazione.

Normalmente a casa il volume e la frequenza dei backup non dovrebbero essere così elevati, qua si parla di scritture dell' ordine di diversi Gb da fare molto frequentemente, non credo che in ambito casalingo si debbano salvare TB di dati ogni settimana
giovanni6914 Settembre 2020, 16:31 #6
Scusami ma non servono TB per saturare ripetutamente una cache da 256MB. Basta avere a che fare con un backup da 500 GB settimanali, da cui derivano qualche centinaio di file di immagine da scrivere (se si usa la segmentazione).
Comunque ci siamo capiti.
Slater9114 Settembre 2020, 16:39 #7
Originariamente inviato da: giovanni69
Grazie per il chiarimento. Il test evidenzia che "la cache ha, però, dei limiti nella sua capacità di supplire ai deficit intrinseci della tecnologia SMR" , similmente ad un SSD privo di cache (es. il noto decadimento del Crucial BX) rispetto a quelli che ne sono forniti . Non si nota tranne quando si iniziano trasferimenti di dimensione sostanziosa.

Avete scritto che l'utilizzo di Linux è stato adottato per facilitare il test, per renderlo possibile agilmente. " in questo modo si può specificare una dimensione del blocco che vada a saturare completamente la cache, esponendone eventuali limiti."
Questo non vuol dire che quanto avete testato non debba trovare riscontro anche nel mondo reale: basta copiare/incollare ripetutamente files che superano quei 256MB, no?

No. La dimensione del blocco non è la dimensione del file. Il motivo per cui ho usato DD è che permette di specificare, usando l'opzione "bs", quanti dati devono essere trasferiti in una volta sola, ovvero qual è la dimensione del blocco da scrivere. Ho usato 256 MB come dimensione proprio per mettere sotto stress il disco, ma oggigiorno i blocchi sono spesso da 4 KB (prima erano da 512 B). Quindi, in teoria, se trasferisci un file da 512 MB non lo fai in due tranche da 256 MB, ma in 128.000 tranche da 4 KB. Ergo, per saturare la cache devi fare parecchie scritture e letture per mettere in difficoltà l'algoritmo di caching (che non ho idea di quale sia in questo caso, spesso si usano varianti avanzate dell'algoritmo dell'ascensore).

Originariamente inviato da: giovanni69
"Il test non è rappresentativo dell'utilizzo "normale" di un disco. "
Si mette in difficoltà non rappresentativa un disco copiando blocchi superiore alla cache da 256MB? Non mi pare un'operazione così estrema, anzi per me è piuttosto rappresentativa nel caso di scritture di file di media dimensione (es segmenti di immagine di backup).

Ti pare che non sia un'operazione così estrema perché mi sembra (ma mi potrei sbagliare) che tu non abbia ben presente come funzionano i trasferimenti di file e le cache su un hard disk.

Originariamente inviato da: giovanni69
E " Tali operazioni [garbage collection], però, vengono eseguite dal disco senza considerare eventuali altre attività in corso". Se questo vi sembra normale... ok.

E non possiamo che ringraziarvi per aver evidenziato i punti deboli.


Ti prego di segnalarmi dove avrei scritto che mi sembra normale. Mi risulta di aver scritto così: "L'impossibilità di prevedere quando ciò [l'avvio della garbage collection] possa accadere rende i dischi SMR meno affidabili di quelli CMR da un punto di vista prestazionale."
Lanfi14 Settembre 2020, 16:41 #8
Originariamente inviato da: giovanni69

Veramente anche in ambito casalingo si può aver necessità di effettuare backup, operazione squisitamente in scrittura, nel caso in cui venisse utilizzato questo SMR come destinazione.


Beh però inquadriamo il problema nel giusto contesto. In un nas casalingo se ogni tanto c'è un rallentamento nella scrittura dei files non mi pare che si tratti di un problema insormontabile. Come scritto sopra l'importante è che la coerenza del file sia garantita.

Per come la vedo il vero problema stava nel non pubblicare la specifica smr nel datasheet del prodotto. Questo poteva portare a notevoli scocciature....pensate ad esempio ad un hard disk smr in raid con un hard disk cmr .

In generale quindi ci sta di introdurre una tecnologia che, pur con qualche limitazione, permetta di abbassare il prezzo al terabyte....l'importante è non vendere una cosa per un'altra.
giovanni6914 Settembre 2020, 16:45 #9
@Slater91: Ringrazio per i chiarimenti. E mi scuso per aver preso lucciole per lanterne


Quanto al " Se questo vi sembra normale." è un mio commento; non l'ho attribuito a te. Infatti era al di fuori del tuo testo che ho riportato tra apici.
WarSide14 Settembre 2020, 16:51 #10
Originariamente inviato da: Lanfi
Beh però inquadriamo il problema nel giusto contesto. In un nas casalingo se ogni tanto c'è un rallentamento nella scrittura dei files non mi pare che si tratti di un problema insormontabile. Come scritto sopra l'importante è che la coerenza del file sia garantita.


Se il NAS ti vomita randomicamente un disco dall'array raid e parte il rebuild, direi che un bel po' ti girano i c@gli@ni.

Se poi si inchiodano 2 HD in contemporanea, puoi anche trovarti con il controller raid che ti vomita 2HD su 4 ed il raid KO con conseguente necessità di fare un recupero dati.

I dischi SMR NON vanno usati in raid. Punto.

Per quanto mi riguarda, non vanno proprio comprati a prescindere per evitare che i produttori spingano sempre più su quest'aborto di tecnologia.

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
^