SSD: thread generale e consigli per gli acquisti

[s12a]

In tal caso ti conviene quello che ti costa di meno.

[killeragosta90]

Originariamente inviato da s12a

In linea generale sì, ma il calo avviene solo in scrittura.
Alcuni SSD con molto spazio di overprovisioning di fabbrica (quelli enterprise in particolare) avvertono molto poco o per nulla il calo prestazionale in scrittura.

A livello consumer qual è la serie che soffre meno del "probema"?

[s12a]

Originariamente inviato da killeragosta90

A livello consumer qual è la serie che soffre meno del "probema"?

Di serie, quelli con controller Indilinx Barefoot 3 come l'OCZ Vector, oppure quelli con controller LAMD come il Corsair Neutron. A dire la verità però un po' tutti i modelli "prosumer" aumentando l'overprovisioning a circa il 25% della memoria NAND flash che fisicamente hanno, si comportano bene. Guarda qui, sezione "performance consistency" con il grafico che permette di fare switch fra IOPs a default/25% OP in caso di scritture sostenute:

http://www.anandtech.com/show/7480/o...240gb-review/2

In sostanza, più OP c'è meglio è, ma bisogna usare i drive in maniera veramente intensa oppure senza supporto al trim per accorgersi della differenza, nella pratica.

EDIT: gli Intel 530 e 335 vanno pure meglio in tal senso, ma aumentare l'OP con questi non apporta molti benefici:
http://www.anandtech.com/show/7438/i...240gb-review/2

[killeragosta90]

Originariamente inviato da s12a

Di serie, quelli con controller Indilinx Barefoot 3 come l'OCZ Vector, oppure quelli con controller LAMD come il Corsair Neutron. A dire la verità però un po' tutti i modelli "prosumer" aumentando l'overprovisioning a circa il 25% della memoria NAND flash che fisicamente hanno, si comportano bene. Guarda qui, sezione "performance consistency" con il grafico che permette di fare switch fra IOPs a default/25% OP in caso di scritture sostenute:

http://www.anandtech.com/show/7480/o...240gb-review/2

In sostanza, più OP c'è meglio è, ma bisogna usare i drive in maniera veramente intensa oppure senza supporto al trim per accorgersi della differenza, nella pratica.

EDIT: gli Intel 520 e 335 vanno pure meglio in tal senso, ma aumentare l'OP con questi non apporta molti benefici
http://www.anandtech.com/show/7438/i...240gb-review/2

Grazie mille per la risposta più che completa!

[Trotto@81]

Originariamente inviato da s12a

Quanto al numero di partizioni ne facevo una questione pratica. Se ti servono più partizioni, partiziona pure.

Sappi però che Linux supporta trim solo sulle partizioni ext4 (e poche altre) e Windows solo su quelle NTFS. Questo implica che lo spazio libero non trimmato nelle partizioni non supportate dal sistema operativo in uso non viene visto come tale dal controller dell'SSD.

Su Linux c'è il comando fstrim che forza il trim esplicitamente su tutto spazio libero (solo ext4 e un paio di altri FS). Su Windows 8 c'è analogamente il comando defrag /L (solo NTFS). Su Windows 7 questo comando non è supportato, di solito si usa fare con i tool dei produttori degli SSD, se presenti.

Come buona pratica da effettuare, non necessaria, ma benefica a lungo termine, consiglierei di trimmare esplicitamente lo spazio libero delle partizioni riconosciute dall'OS con tali comandi prima di fare boot sull'altro OS.

Non sei stato chiaro, almeno per me. A cosa servirebbe forzare il trim su file system supportati e sul quale il trim lavora continuamente?

[s12a]

Originariamente inviato da Trotto@81

Non sei stato chiaro, almeno per me. A cosa servirebbe forzare il trim su file system supportati e sul quale il trim lavora continuamente?

Il supporto di base al trim da parte del file system (di default su NTFS Windows 7/8 e da attivare manualmente su Linux sulle partizioni ext4 aggiungendo il flag discard in fstab) funziona in tempo reale solo sui settori logici corrispondenti ai file cancellati. Ne consegue che con il tempo si verrà a formare una certa quantità di spazio spazio libero venutosi a creare in seguito ad altri eventi (es. modifica file), ma non trimmato.

Questo di per sé non è una cosa grave. Non è che sull'SSD rimarranno celle di memoria non trimmate. Il wear leveling previene questa cosa. Il punto è che è una cosa graduale nel tempo, lenta. Una certa percentuale di spazio libero rimarrà sempre "sporcata" (o equivalente a contenente dati utili) dal punto di vista del controller dell'SSD.

Forzando il trim su tutto lo spazio libero riconosciuto e supportato dal sistema operativo con comandi appositi, invece, hai la sicurezza che il sistema operativo segnalerà lo stesso come tale al controller dell'SSD nella sua interezza. E ciò avviene in tempi tempi brevissimi, praticamente istantanei.

Facendo così, quando si passerà mediante dual boot all'altro sistema operativo, lo spazio libero non supportato/non riconosciuto da esso, essendo stato tutto trimmato, sarà completamente disponibile all'SSD per le operazioni di wear leveling.

Se però da Linux ci mettiamo a scrivere/modificare dati sulla partizione di Windows NTFS (su cui Linux non supporta il TRIM) precedentemente trimmata, "sporcheremo" tale spazio e lo toglieremo al controller dell'SSD fino a quando non faremo nuovamente logging a Windows effettuando un'altra passata di TRIM "forzato" su tutto lo spazio libero lì riconosciuto.

[Trotto@81]

Scusami se insisto, ma la cella di un file modificato che senso ha trimmarla? Non si trimmano solo le celle contenenti file non più utili? Un file modificato è un file ancora utile. Dal man di fstrim mi pare di capire che avverrà tutto in automatico senza intervento manuale, come è logico che sia.
http://man7.org/linux/man-pages/man8/fstrim.8.html

[s12a]

Originariamente inviato da Trotto@81

Scusami se insisto, ma la cella di un file modificato che senso ha trimmarla? Non si trimmano solo le celle contenenti file non più utili? Un file modificato è un file ancora utile.

Se un file modificato diminuisce di dimensione, (diventa più piccolo), lo spazio libero che si viene a creare non viene trimmato. Per quanto ne sappia, ad oggi il trim in rempo reale su Windows e Linux opera solo in seguito a cancellazioni di file.

[Trotto@81]

Originariamente inviato da s12a

Se un file modificato diminuisce di dimensione, (diventa più piccolo), lo spazio libero che si viene a creare non viene trimmato. Per quanto ne sappia, ad oggi il trim in rempo reale su Windows e Linux opera solo in seguito a cancellazioni di file.

https://patrick-nagel.net/blog/archives/337
A quanto pare fstrim è superfluo se hai abilitato l'opzione discard, e per fortuna direi. Questa persona addirittura sconsiglia di usarlo se si vogliono le massime prestazioni dal proprio disco e di schedulare il comando fstrim per mantenerlo in forma. L'operazione non è proprio istantanea dato che a lui impiega 6 minuti con 95 GiB occupati.

[ANDREAHF]

SSD interno SAMSUNG 840 EVO 2,5" , 120GB

Va bene per portatile di 5 anni fa con Vista?

[s12a]

Originariamente inviato da Trotto@81

https://patrick-nagel.net/blog/archives/337
A quanto pare fstrim è superfluo se hai abilitato l'opzione discard, e per fortuna direi. Questa persona addirittura sconsiglia di usarlo se si vogliono le massime prestazioni dal proprio disco e di schedulare il comando fstrim per mantenerlo in forma. L'operazione non è proprio istantanea dato che a lui impiega 6 minuti con 95 GiB occupati.

"A quanto pare" no. Non è quello che dice l'autore.

Nel suo caso specifico, con SSD assai vecchio/obsoleto (OCZ Vertex LE), sia fstrim che il trim in tempo reale sono lenti, ma con fstrim può scegliere lui quando perdere tempo a fare trim, mentre con discard questo succede ogni volta che si cancella un file (come menzionato sopra), dato che il trim viene invocato sui settori corrispondenti in maniera automatica, e la conseguenza di ciò è che cancellare molti file insieme diventa un'operazione molto più lenta del normale (rispetto a non usare trim). Questo è anche perché il flag discard su Linux non invoca il trim in maniera ottimale (non fa batching, viene eseguito nel momento immediatamente successivo a quello in cui si cancella un file), motivo per il quale è ad oggi disabilitato di default nella maggior parte dei casi.

Su un SSD moderno in ogni caso questo problema di lentezza non c'è. I moderni controller gestiscono il trim in maniera più intelligente, a priorità più bassa invece che esclusiva. Questo comportamento è stato migliorato anche dal punto di vista delle specifiche SATA, che dalla revisione 3.1 prevedono il deferred trim (viene eseguito in un secondo momento a seconda delle condizioni di utilizzo, non necessariamente al momento dell'invocazione).

In ogni caso secondo la mia esperienza di utilizzo personale con fstrim sui Samsung 830/840 l'operazione è quasi istantanea. Sugli SSD con controller Sandforce (provato recentemente con un Kingston V300) l'operazione è un po' più lenta, ma sempre piuttosto veloce; di certo non ci vogliono minuti per trimmare svariate decine di GB di spazio libero.

Sugli SSD moderni su Linux il flag discard può nell'uso comune sostituire fstrim dato che la penalità di velocità nelle operazioni comuni è piccola, ma non è efficiente come esso, come ho spiegato in un precedente commento. Per lo stesso identico motivo su Windows 8 è stata aggiunta la funzionalità di "ottimizzazione" che oltre al supporto del trim in seguito a cancellazioni già presente su 7, aggiunge anche quello a livello di partizione di tutto lo spazio libero, come fstrim.

Effettuarli entrambi, con il secondo ad intervalli programmati (come già succede su Windows) è certamente la soluzione migliore dal punto di vista dell'SSD, ma non è che sia indispensabile.

[Pess]

Originariamente inviato da ANDREAHF

SSD interno SAMSUNG 840 EVO 2,5" , 120GB

Va bene per portatile di 5 anni fa con Vista?

Si, va benissimo!

[Trotto@81]

Originariamente inviato da s12a

Effettuarli entrambi, con il secondo ad intervalli programmati (come già succede su Windows) è certamente la soluzione migliore dal punto di vista dell'SSD, ma non è che sia indispensabile.

Non è che non voglia crederti, ma sulla base di sole ipotesi è per me impossibile farlo. Se mi dai link a tale argomento te ne sono grato, sono qui per imparare. Meglio se inerenti Linux, Windows non mi interessa più di tanto.

[Lorenzoz]

Visto che si parla dell'amato linux mi inserisco.

Dovrebbero arrivare buoni miglioramenti nel kernel 3.13 per quanto riguarda velocità degli SSD e peso delle operazioni sulla CPU.

Magari sarà migliore anche il trim? Non so non sono un drago su queste cose.

qui

[s12a]

Originariamente inviato da Trotto@81

Non è che non voglia crederti, ma sulla base di sole ipotesi è per me impossibile farlo. Se mi dai link a tale argomento te ne sono grato, sono qui per imparare. Meglio se inerenti Linux, Windows non mi interessa più di tanto.

Tecnicamente, quando il flag discard è abilitato su ext4, viene eseguito il trim quando il file system libera dei blocchi in maniera esplicita:

http://git.kernel.org/cgit/linux/ker...1ee87bf4cae0a4

discard/nodiscard
Controls whether ext4 should issue discard/TRIM commands to the
underlying block device when blocks are freed. This is useful
for SSD devices and sparse/thinly-provisioned LUNs, but it is
off by default until sufficient testing has been done.

Quando succede questo, nella pratica? A parte quando si cancellano dei file (esplicitamente o indirettamente, ad esempio in seguito ad uno spostamento verso un'altra partizione), situazione in cui il trim certamente funziona e che provoca problemi prestazionali con certi SSD, motivo per il quale su Linux si tende a consigliare di effettuare piuttosto l'operazione manualmente con fstrim?

Originariamente inviato da Lorenzoz

Visto che si parla dell'amato linux mi inserisco.

Dovrebbero arrivare buoni miglioramenti nel kernel 3.13 per quanto riguarda velocità degli SSD e peso delle operazioni sulla CPU.

Quello che serve è un miglioramento generalizzato di come funziona il TRIM in real time su linux, mi sembra che quanto linkato non abbia molto a che vedere con esso.

Piuttosto, il team di Ubuntu ha intenzione di abilitare il TRIM in maniera automatica sugli SSD nel futuro, ma non con il flag discard, bensì con un comando fstrim ad intervalli programmati, almeno per quanto riguarda le distribuzioni desktop. Per la versione smartphone il contrario, invece:

http://www.phoronix.com/scan.php?pag...tem&px=MTUxOTY

...Ubuntu developers aren't looking to enable discard at the file-system level since it can slow down delete operations, so instead they're wanting to have a new cron job that routinely runs fstrim for TRIMing the system.

This new cron job for Ubuntu Linux will check for mounted file-systems not using the file-system level discard option, ensure that it's an SSD being used that supports TRIM, and then call on fstrim. For the phone version of Ubuntu they are discussing though just adding the discard flag for file-system mounting.

[Lorenzoz]

Originariamente inviato da s12a

Quello che serve è un miglioramento generalizzato di come funziona il TRIM in real time su linux, mi sembra che quanto linkato non abbia molto a che vedere con esso.

Ah ok, pensavo che una distribuzione migliore dei carichi tra le CPU potesse rendere meno avvertibili i rallentamenti di cui parlavate prima.
Del resto sto parlando da non possesore di SSD quindi non ho idea.

Originariamente inviato da s12a

Piuttosto, il team di Ubuntu ha intenzione di abilitare il TRIM in maniera automatica sugli SSD nel futuro, ma non con il flag discard, bensì con un comando fstrim ad intervalli programmati, almeno per quanto riguarda le distribuzioni desktop. Per la versione smartphone il contrario, invece:

http://www.phoronix.com/scan.php?pag...tem&px=MTUxOTY

Letto anche quello, speriamo.

[maxmax80]

Originariamente inviato da HSH

ciao ragazzi, posseggo un m4 da 128gb e prossimamente penso di sostituirlo con un 256 samsung 840, secondo voi per uso ludico conviene l EVO o il pro?

se non hai esigenze di spazio, io mi terrei tranquillamente l' M4

[Pess]

Originariamente inviato da maxmax80

se non hai esigenze di spazio, io mi terrei tranquillamente l' M4

Quoto... Cmq per uno ludico puoi andare tranquillamente di EVO...

[psychok9]

L'altra notte (nerdaggine pura), riflettevo sull'SSD rispetto ai dischi magnetici, e l'impatto delle partizioni.

Installando il sistema operativo, fisicamente, nella parte iniziale del disco magnetico (esterna, la più veloce) con l'opportuna partizione che di solito è una frazione del disco, i file rimanevano appunto in quella zona "esterna" e veloce con velocità di accesso migliori.

Con gli SSD, quando partizioniamo, come si comporta? Perché al contrario dei dischi magnetici, sarebbe bene, per la durata degli SSD, contenere la scrittura, ad esempio del sistema operativo, sempre nelle stesse zone... ma avviene ancora si? ...o l'elettronica pensa ad "astrarre" le partizioni e quindi alla fine i file vengono sparsi al meglio su tutte le memorie elettroniche?

[s12a]

Gli algoritmi di wear leveling degli SSD si occupano in maniera automatica e continua nel tempo/con l'uso, di rimescolare i blocchi fisici di memoria assegnati ai blocchi logici usati dal sistema operativo, in maniera a quest'ultimo trasparente.