Situazione Trim su SSD Samsung 8* series

[bingel]

Possiedo un SSD Samsung 840 Pro.
Vorrei aggiornare il firmware ma sono un po' indeciso per via della famosa questione dei bug emersa ad inizio estate 2015.
Ho sempre usato il "discard" in "/etc/fstab" (sulla 12.04) e non ho mai avuto problemi, devo dire però che non movimento grosse quantità di dati.
Ieri ho dato un'occhiata a diverse discussioni per capire se Samsung avesse risolto o meno il problema ma non c'ho capito granché.
Ho visto che alcuni dispositivi (l'intera serie 8*) sono stati blacklistati nel kernel mentre altri (SSD Samsung senza indicazione della serie o del modello) sono stati whitelistati.
Questo accadeva più di un anno fa per cui mi chiedo ora quale sia lo stato dell'arte.

Grazie in anticipo a chi saprà darmi qualche delucidazione.

[DoctorStrange]

Non capisco per quale motivo dovresti tentare un'operazione potenzialmente pericolosa per il tuo drive, se questo sembra non ti abbia creato problemi di alcun tipo.

Hai riscontrato un problema di qualche tipo?

Inoltre non dici nulla a riguardo al bug di cui parli.

A me sembra una cosa un pò troppo di nicchia, o comunque una qualche genere di ottimizzazione rivolta a chi fa un uso intensivo di questo genere di drive, come i data center e non mi sembra il caso di chi usa il computer in maniera normale.

Io ho un SSD non di ottima marca come la tua, ed il mio è targato per un funzionamento ottimale fino ad otto anni, prima che sopraggiungano problemi irreversibili, e sono parimenti certo che il mio computer non avrà un'aspettativa di vita così lunga, ciò nonostante non ho mai, e non cambierò mai il firmware del drive.

Saluti

[bingel]

Volevo aggiornare il firmware perché ho appena reinstallato Ubuntu. Sono passato dalla 12.04 alla 16.04 e quindi volevo cogliere l'occasione per sistemare un po' di cose. Inoltre, aggiornare il firmware degli SSD solitamente è utile (ovviamente immagino sia meglio anche fare un backup dei dati).
Del problema dei Samsung se ne è parlato molto ed è piuttosto noto per questo non sono stato a riportarlo. Inoltre, suppongo che chi dovesse intervenire per delucidarmi, lo conosca di certo.
Si parla di corruzione di dati qualora si imposti il trim online (tramite discard) ma onestamente non so quando il problema si verifichi (immagino anch'io muovendo grosse quantità di dati). Non ho capito inoltre se pur impostando il trim in tale modo, il kernel, se rileva un ssd Samsung non lo esegue (visto che esiste una blacklist). In ogni caso se qualcuno ha info più fresche mi farebbe piacere sapere come stanno attualmente le cose e se l'ultimo firmware abbia risolto il problema (e se, di conseguenza, gli SSD in questione siano stati tolti dalla blacklist all'interno del Kernel).

EDIT: oltre al problema di cui sopra, ne esisteva un altro (meno importante e poi corretto dalla stessa Samsung tramite una patch al kernel) per cui si erano riscontrati dati corrotti quando gli SSD facevano parte di un raid. In questo caso, ovviamente, non riguardava il firmware Samsung bensì il kernel linux.

[Mdfalcubo]

Sposto al bar, non mi pare che il problema riguardi direttamente Ubuntu.

[bingel]

Non so, mi sembra comunque più un problema tecnico che da bar.

Anche perché le domande implicite sarebbero:

- è sicuro abilitare il discard se si possiede uno dei dischi incriminati?
- verrebbe ignorato o meno visto che sono già stati messi in blacklist?
- l'ultimo firmware corregge o meno il problema?

[Janvitus]

Un fstrim settimanale è meglio di un discard, su qualsiasi disco.

[bingel]

Come sei giunto a questa conclusione? Perché su un vecchio thread che ho letto proprio ieri, affermavi praticamente il contrario.

EDIT:

Credo di saperne un "po'", ma giusto un "po'" di Linux, e ho una SSD da quasi 3 anni... Se consiglio di mettere discard, noatime, cambiare lo scheduler e mettere ext4 come FS (la tmpfs sulla ram per i più temerari), ci sarà un perché. Leggete un po' quello che abbiamo scritto precedentemente su questo forum.

Di seguito il link: http://forum.ubuntu-it.org/viewtopic.ph ... 0#p4836654

...e comunque, bug a parte, mi pare di aver letto da qualche parte che il discard sarebbe invece la scelta ottimale (ovviamente dev'essere supportato) ma onestamente non ne sono molto convinto neppure io.

[bingel]

PROMEMORIA:

- i primi problemi con gli SSD Samsung sono stati ravvisati sugli 840 EVO che faticavano a leggere dati scritti ad una certa distanza di tempo (vecchi) come se si smemorizzassero. Un aggiornamento del firmware ha risolto questa cosa nel modo seguente: i vecchi dati venivano riscritti in background in maniera da rinfrescarli. Il problema non riguardava i modelli PRO ma soltanto gli EVO e gli 840 (senza ulteriore dicitura) in quanto usavano un differente tipo di memorie NAND (più economiche).

- Il nuovo firmware ha risolto questo problema ma stando a quanto sostiene qualcuno, ne ha introdotto uno nuovo che questa volta riguarda tutta la serie 8* (inizialmente credo sia stato rilevato su un 850 PRO). Ora il cosiddetto queued trim (discard) non funziona più a dovere per via di alcune istruzioni non corrette. I file sotto una determinata dimensione vengono cancellati e quelli più grandi risultano corrotti.
Mi resta il dubbio che questo bug preesistesse alla nuova versione del fw tuttavia questo link sembrerebbe fugarlo: https://github.com/torvalds/linux/commi ... 8ae67acf81
Stando a questo link, sembrerebbe tuttavia che il trim non funzionasse correttamente neppure col vecchio firmware però il vecchio fw non "pubblicizzava" questa funzionalità che quindi era come se non ci fosse e non veniva usata (e di conseguenza non creava problemi).

- contemporaneamente è stato scoperto un altro bug che provocava perdita di dati e riguardava il layer md (raid 0 e raid 10). Questa volta, tuttavia, il problema era relativo al kernel Linux ed è stato risolto con una patch da parte di Samsung.

Gli SSD incriminati sono stati blacklistati e il kernel, a partire da una determinata versione, ha cominciato a impedire il queued trim (trim continuo) ovvero il mount delle partizioni con opzione "discard" (ed in effetti, stando a qualcuno che ha fatto dei test indicando tale opzione nel fstab, la partizione veniva comunque montata senza l'opzione, ignorandola). Si può verificare direttamente quanto detto relativamente agli SSD messi in blacklist anche visualizzando le modifiche subite dal codice sorgente della libreria "libata-core.c".

Io ho provato a fare lo stesso test sulla mia ubuntu 16.04 con su l'ultimo kernel e l'opzione ora sembra invece essere considerata perché mettendo "discard" in "/etc/fstab" ed andando poi a verificare con "mount", l'opzione "discard" risulta tra l'output relativo alla partizione per cui avevo abilitato il queued trim con "discard".

Mi chiedo dunque se nel frattempo gli SSD siano stati whitelistati ed eventualmente in base a quale criterio perché se uno non avesse aggiornato il firmware (o viceversa visto che non so di preciso quale sarebbe il fw contenente il bug) potrebbe andare comunque incontro al problema.

[Janvitus]

Come sei giunto a questa conclusione? Perché su un vecchio thread che ho letto proprio ieri, affermavi praticamente il contrario.

Solo gli scemi non cambiano mai opinione su qualcosa

[Mdfalcubo]

Boh io ho un evo pro 850 da un paio di anni (se non ricordo male) e non ho riscontrato alcun problema in merito al/ai bug di cui parli. Tra privacy e ssd per me ti stai intraminando un po' troppo

[bingel]

@Janvitus:
certo ma a me più che altro interesserebbe capire come ti sei fatto quella nuova (visto che affermavi di avere le idee piuttosto chiare in merito) perché come ho detto e come mi parrebbe più logico (sebbene non ne sia convinto nemmeno io), il "discard" trim dovrebbe essere migliore del trim schedulato in quanto, tenendo costantemente informato il disco fisso delle variazioni avvenute nel file system, si aumenta la probabilità di non cancellare interi blocchi di dati qualora non fosse necessario (o qualcosa del genere, sto andando a memoria). Non ho neppure capito se in termini di prestazioni sia meglio o peggio perché eseguendo continuamente questa sorta di aggiornamento si crea un flusso di informazioni che impegnano la banda ma d'altro canto il disco, beneficiandone, dovrebbe "reagire" meglio e complessivamente trarne vantaggio. E' d'altro canto vero che in base a quanto ho letto, il firmware di buona parte degli SSD in commercio non gestisce troppo bene il queued trim per cui questa, già da sola, sarebbe una buona ragione per optare per quello schedulato. Boh!

@Mdf:
della privacy mi interessa relativamente. Dal tono con cui ho iniziato la discussione forse posso sembrare preoccupato (difficile farsi comprendere per iscritto) ma in realtà l'ho buttata là giusto per scambiare un paio d'opinioni. Un po' indignato però lo sono, questo è vero.
Sono argomenti del resto, come giustamente fa notare qualcuno, anche abbastanza vecchi e probabilmente già trattati. Tuttavia ritengo non si debba abbassare troppo la guardia. FINE OT

Per quanto riguarda i bug invece mi piacerebbe arrivare ad una conclusione perché in tutta onestà ci sto capendo sempre meno (per certe cose, per altre mi sono schiarito abbastanza le idee) e l'affidabilità del disco fisso è importante, tanto più se penso che in quel Samsung c'avevo speso un bel po' di soldi e mi era stato consigliato come il non-plus-ultra in quella fascia. Invece dall'estate scorsa sono cominciati ad emergere diversi problemi (non a me direttamente, mi riferisco a ciò che ho letto in giro) che non mi fanno stare troppo tranquillo.

Stamattina, ad esempio, ho dato un'occhiata ai sorgenti del kernel che ho attualmente installato (driver/ata/libata-core.c) e i Samsung della serie 8* risultano essere ancora in blacklist. Questo significa che se io metto "discard" nelle opzioni di una partizione nell' "fstab", tale opzione dovrebbe essere ignorata. Invece se una volta rimontata la partizione, vado a verificare nell'output di "mount", trovo, tra le opzioni relative alla partizione in questione, che è presente anche "discard". Ho letto da qualche parte, invece, che qualcuno, in mezzo a tale output non ce la trovava (e forse è così che deve essere ma può anche darsi che pur venendo riportata, in realtà sia comunque ignorata) per cui mi piacerebbe capire perché invece da me non è così.

Perché poi, tra l'altro, mi viene un altro dubbio. Avendo utilizzato per anni la 12.04 con l'opzione discard attivata, temo che in realtà, durante tutto quel tempo non sia stato eseguito alcun trim (non credo che nella 12.04 fosse previsto il trim settimanale) visto che a quanto pare, il trim continuo nei vecchi firmware non era "pubblicizzato" (uso questo termine perché è la traduzione dall'inglese, in pratica significa che tale funzionalità, sebbene presente non veniva resa nota) e il kernel dunque non lo eseguiva.
Il problema infatti è cominciato ad emergere quando negli ultimi firmware, tale funzionalità (trim continuo) ha cominciato ad essere pubblicizzata ed il kernel ha cominciato ad usarla. Siccome però le istruzioni dei firmware Samsung non erano corrette per via di una cattiva interpretazione dello "standard ata", ecco che è accaduto quel che è accaduto (vedi vicenda Algolia). E a quanto pare, i nuovi firmware Samsung non hanno ancora risolto il problema (ammesso che ci sia volontà da parte di Samsung visto che mi sorge anche questo dubbio) perché altrimenti, almeno questi, sarebbero stati messi in whitelist.

[Janvitus]

@Janvitus:
certo ma a me più che altro interesserebbe capire come ti sei fatto quella nuova (visto che affermavi di avere le idee piuttosto chiare in merito) perché come ho detto e come mi parrebbe più logico (sebbene non ne sia convinto nemmeno io), il "discard" trim dovrebbe essere migliore del trim schedulato in quanto, tenendo costantemente informato il disco fisso delle variazioni avvenute nel file system, si aumenta la probabilità di non cancellare interi blocchi di dati qualora non fosse necessario (o qualcosa del genere, sto andando a memoria). Non ho neppure capito se in termini di prestazioni sia meglio o peggio perché eseguendo continuamente questa sorta di aggiornamento si crea un flusso di informazioni che impegnano la banda ma d'altro canto il disco, beneficiandone, dovrebbe "reagire" meglio e complessivamente trarne vantaggio. E' d'altro canto vero che in base a quanto ho letto, il firmware di buona parte degli SSD in commercio non gestisce troppo bene il queued trim per cui questa, già da sola, sarebbe una buona ragione per optare per quello schedulato. Boh!

Leggendo nuove cose sul discrd e l'fstrim, ora non ricordo come sono arrivato alla conclusione, dovrei rivedere le varie pagine su cui mi sono documentato, fatta sta che l'fstrim funziona meglio, e oltretutto, da quando sono passato da discard a fstrim il disco ssd è più veloce nelle varie operazioni di spostamento ed eliminazione dei file.

[woddy68]

Scusate l'intrusione...secondo voi per Ubuntu quale file system è meglio utilizzare per un SSD ?

[bingel]

Ext4

[woddy68]

Ext4

Ok grazie, quindi lascio ext4.

[bingel]

Btrfs potrebbe essere una valida alternativa, anzi, come file system è anche più moderno ma io credo che per ext4 il supporto, almeno su Ubuntu, sia maggiore e visto che ext4 gli SSD li supporta tranquillamente (trim) non c'è ragione, secondo me, di andarsi a complicare la vita con cose non standard.

[bingel]

@Janvitus
Bene. Buono a sapersi.
Quali altre ottimizzazioni hai adottato? Per esempio io tra relatime e noatime opterei per il primo che tra l'altro è anche il default.
Un elenco sintetico delle tue ottimizzazioni?

[bingel]

PROMEMORIA:

Un link che paragona fstrim con discard:

- http://blog.neutrino.es/2013/howto-prop ... d-dmcrypt/

...concludendo che fstrim è migliore.

Un altro link:

- https://patrick-nagel.net/blog/archives/337

Una guida per l'ottimizzazione:

- https://wiki.debian.org/SSDOptimization

Il log delle modifiche alla "libreria libata-core.c":

- https://github.com/torvalds/linux/commi ... GzLuTBKzM0

[Janvitus]

@Janvitus
Bene. Buono a sapersi.
Quali altre ottimizzazioni hai adottato? Per esempio io tra relatime e noatime opterei per il primo che tra l'altro è anche il default.
Un elenco sintetico delle tue ottimizzazioni?

Abilitare fstrim con systemd (c'è il servizio apposito), mettere la /tmp in ram (cosa che fedora fa automaticamente), cambiare lo scheduler dei dischi, cfq quello meccanico e deadline quello solido, e mettere noatime nell'fstab alle partizioni sull'ssd.

[bingel]

Usare systemd o lo script di crontab cambia qualcosa?
Quanto a noatime, non è meglio relatime? Mi pare che con il secondo non aumentino poi di così tanto le scritture su disco e si evitino eventuali problemi con quei programmi a cui non piace che la data di accesso sia precedente a quella di modifica.