Smart, SSD e durata

Ho acquistato come disco principale del mio computer un
SDD Samsung ssd 840pro da 128GB con memoria nand MLC da 3000 P/E Cycles (program/erase)

Vorrei capire, coi miei ritmi attuali, quanto tempo potrà durarmi l'ssd prima che la memoria nand perda le sue proprietà di memorizzare dati (di tenere la carica sostanzialmente)

Per fare i calcoli di trasformazioni bit-byte-MiB etc mi aiuto con questo
http://www.matisse.net/bitcalc/?input_amount=449224331264&input_units=bytes&notation=legacy

Col comando smartctl si possono leggere tutti i parametri smart, in particolare mi concentro su uno di essi, Total_LBAs_written

Poi guardo la dimensione dei settori sul disco

Qui c'è un po' di confusione nella nomenclatura, il termine block size può riferirsi
1- Hardware block size, chiamato anche “sector size”: La più piccola porzione di dati indirizzabile  sull'hard-disk
2- Filesystem block size, chiamato anche nella nomenclatura fat “cluster size”: La più piccola porzione di dati indirizzabile sul file system. (il discorso è ovviamente più complesso).
3 – Buffer cache size (che non ci interessa)

LBA (Logical Block Address) è un sistema logico di numerazione degli Hardware Block size, ovvero dei settori, parte da 0 fino a un offset massimo.

Per verificare questo fai

 

Dimentichiamoci per un attimo del termine block che, a mio parere, viene calcolato da fdisk facendo una supposizione errata (ovvero supponendo blocchi da 1KiB)

Prendo la mia home, ovvero sda6
Faccio la differenza fra il settore finale e il settore iniziale 199817215−97417216 = 102399999
Questo è il numero di blocchi
102399999×512=52428799488 byte, ovvero 48GiB

Guardiamo lo spazio vuoto tra l'inizio del disco e la prima partizione
Parte da 0 e arriva al settore 2048. Quindi ha 2048settori grossi 512byte l'uno per un totale di 1048576 che è esattamente 1MiB

Quindi in generale

|--------------------------------------------------1Mib------------------------------------------------|
|--512B-|
|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|
0          1           2....                                                                                                        2048

LBA0-Settore0 – Hardware Block 0   - 0Byte
LBA1-Settore 1 -  Hardware Block 1  - 512Byte
LBA2- Settore2 –  Hardware Block 2  - 1024Byte (1KiB)
.
.
LBA2048 – Settore 2048 – 2048x512=1MiB

Il termine LBA sector 2048 si riferisce quindi a questa posizione, ovvero dopo 1 MiB (se ne parla perchè windows da vista in avanti allinea la prima partizione da questo lba in avanti)

Questo è un livello di asterazione che viene poi presentato al file system che appunto opera sui “block device”.
Il termine settori è obsoleto e si riferiva a quando si utilizzava il vecchio sistema CHS. Tutti i dischi moderni invece usano LBA e quindi i settori non esistono più: Ora che lo sappiamo però continuiamo a utilizzarlo impropriamente.

Bene ora veniamo al problema iniziale, rileggendo da smartctl abbiamo scritto, in circa 4 mesi
862553777 settori da 512Byte ciascuno, logicamente indirizzati come LBA
Quindi, facendo un po' di matematica
862553777×512 = 441627533824 Byte = 411GiB, quindi supponendo di avere 30 giorni al mese per 4 mesi avremo
411÷120 = 3.425 GiB/giorno di scritture sul disco

Ora queste sono le scritture che arrivano al controller del disco, poi ciò che viene scritto sulla nand è superiore, di quanto non so esattamente. Questo perchè (tra i vari motivi, poi per approfondire ci sono in rete un sacco di articoli sugli ssd e i loro “problemi”) in realtà su un ssd la quantità minima che può essere scritta/letta (pages, per esempio 8KB) è molto minore della quantità minima che può essere cancellata (erase block, per esempio 64pages=512KB), quindi per riscrivere un dato potresti doverne cancellare molti di più, ricopiare quelli che non volevi davvero cancellare, e poi scrivere solo quello che ti interessa.

In ogni caso supponiamo una write amplification di 10x, quindi  supponiamo di scrivere sulla nand 34.25GiB/giorno

Il disco da 128GB è garantito per 3000 cicli, quindi
128GB = 128035676160 Bytes = 119GiB x 3000 P/E cycles = 357000 GiB di cicli di scritture prima di rompersi

Ai miei ritmi di 34GiB/giorno quindi
357000÷34.25 = 10423 Giorni, ovvero 28 anni e mezzo

Ora proviamo il comando

Come tutto il contenuto di /proc anche diskstats viene resettato a ogni reboot del computer, quindi questo dato ha valore solo guardando la data dell'ultimo reboot

Il numero dei campi parte da dopo il nome del disco/partizione (dalla documentazione ufficiale)

Field  1 -- # of reads completed
This is the total number of reads completed successfully.
Field  2 -- # of reads merged, field 6 -- # of writes merged
Reads and writes which are adjacent to each other may be merged for
efficiency.  Thus two 4K reads may become one 8K read before it is
ultimately handed to the disk, and so it will be counted (and queued)
as only one I/O.  This field lets you know how often this was done.
Field  3 -- # of sectors read
This is the total number of sectors read successfully.
Field  4 -- # of milliseconds spent reading
This is the total number of milliseconds spent by all reads (as
measured from __make_request() to end_that_request_last()).
Field  5 -- # of writes completed
This is the total number of writes completed successfully.
Field  7 -- # of sectors written
This is the total number of sectors written successfully.
Field  8 -- # of milliseconds spent writing
This is the total number of milliseconds spent by all writes (as
measured from __make_request() to end_that_request_last()).
Field  9 -- # of I/Os currently in progress
The only field that should go to zero. Incremented as requests are
given to appropriate struct request_queue and decremented as they finish.
Field 10 -- # of milliseconds spent doing I/Os
This field increases so long as field 9 is nonzero.
Field 11 -- weighted # of milliseconds spent doing I/Os
This field is incremented at each I/O start, I/O completion, I/O
merge, or read of these stats by the number of I/Os in progress
(field 9) times the number of milliseconds spent doing I/O since the
last update of this field.  This can provide an easy measure of both
I/O completion time and the backlog that may be accumulating.

Quindi ci serve il valore del campo 7

Il pc è acceso da

Abbiamo 7843884 settori scritti sul disco, moltiplicati per 512 Byte per settore risulta
4016068608 Byte = 3,7GiB di scrittura che è perfettamente in linea col dato calcolato in precedenza.

Se lanciassimo questi 2 comandi entrambi in un tempo t e entrambi in un tempo t+1, dovremmo quindi ottenere la stessa differenza (ovvero il numero di settori/blocchi scritti)

Filesystem Block Size

Per visualizzare la dimensione dei blocchi del file system, che generalementa sarà identica o multipla della dimensione dei blocchi fisici basta dare il comando (in caso di extX)

oppure

HDD
Vediamo un un hdd tradizionale con Advanced Format (ovvero settori fisici da 4k)

Come si vede però la dimensione fisica dei settori (o blocchi hardware come dicevamo prima)è diversa da quella logica. Il disco quindi si presenterà al file system come se avesse ancora i vecchi settori da 512byte e questo è per retrocompatibilità visto che per 20 anni i dischi hanno avuto quella dimensione

Calcolo della dimensione della partizione sdb6
1953523711−84998144=1868525567x512=956685090304=890GiB

Calcolo della dimensione del file sistem creato sulla partizione

233565696x4096=890GiB

Poi se faccio df vedo cose diverse

La differenza tra i 4k blocks dati dal comando df e quelli del tune2fs è dovuta al fatto che una parte del file system è riservata a memorizzare il journal (PENSO)

La differenza tra totale-(userd+avaiable), ovvero 229868053 -(112307534+105882235), che a logica dovrebbe fare zero invece fa 11678284
che è proprio la quantità di blocchi che vedi se dai il comando

In sostanza, come retaggio del passato, la distribuzione che ho usato, quando crea il file-system (ext3/4) , riserva una percentuale di blocchi a root in modo che, anche quando finisci lo spazio, l'utente root è comunque in grado di scrivere eventuali log o altro. Forse però il 5% è un po' troppo, volendo puoi eliminare questa cosa dando il comando
tune2fs -m 0 /dev/sdb6

Un file system fat32 da 100MiB, che quindi non è journaled, si vedrà anche con df grosso 100MiB

HARD DISK DANNEGGIATO

Ora esamino un disco danneggiato collegandolo via usb

Effettuo ora un test offline del disco, che può essere fatto solo se il disco non è montato, altrimenti avrei dovuto fare un test -t short o -t long che può essere fatto anche col disco in uso.

Ora guardo i risultati

i log

i log-error (memorizza solo gli ultim i 5)

A questo punto sappiamo che il primo settore danneggiato sta a lba 877391272. Possiamo quindi creare una partizione prima, lasciare un buco, e creare una partizione dopo sperando quindi di circoscrivere il problema.

WINDOWS - SECTOR SIZE

Per curiosità, per capire la dimensione dei settori su un disco già formattato con ntfs il comando da dare è

Nel mio caso il disco C e E hanno entrambi settori da 512Byte, il disco D ha i settori da 4K e va in emulazione a 512Byte.
I campi da guardare sono "Bytes per Sector" e "Bytes per Physical Sector"

sector_win8

Print Friendly, PDF & Email