Ubuntu: supporto a TRIM abilitato di default dalla 14.04

[Redazione di Hardware Upg]

Link alla notizia: http://www.hwfiles.it/news/ubuntu-su...404_50265.html

Canonical è pronta ad abilitare il supporto a TRIM in via predefinita sul proprio Ubuntu, a partire dalla prossima versione

Click sul link per visualizzare la notizia.

[ezio]

Sulle ultime versioni di OpenSuse va attivato manualmente?

[diabolikum]

Alla buon'ora...

[dobermann77]

Non credo che ci siano distro che lo abbiano attivo di default.

Per questo io sono felice di usare Linux in VirtualBox, dove funziona perfettamente, ha i driver della vm e non puo' fare danni.

[lucreghert]

Bhè...Considerato che tutti gli attuali SSD venduti hanno al loro interno un controller che si occupa di liberare la cella non più utilizzata,direi che non serve a una bella ceppa di nulla affidare questo compito al sistema operativo.
Io sul mio SSD il trim non l'ho mai attivato e secondo i miei test le prestazioni rispetto a quando era nuovo non sono cambiate di una virgola.

[acerbo]

vabbé pero' c'é la ricerca integrata su Amazon

[Cloud76]

Il comando TRIM sarà abilitato in via predefinita già a partire da Ubuntu 14.04. Canonical arriva in ritardo di alcuni anni su una feature considerata di primaria importanza qualora venga utilizzato un SSD.

Il comando TRIM sarà abilitato in via predefinita già a partire da Ubuntu 14.04.

uh, già dalla prossima release, bene sono in anticipo...

Canonical arriva in ritardo di alcuni anni su una feature considerata di primaria importanza qualora venga utilizzato un SSD.

ah no, allora sono in ritardo spaventoso...

Ecco... come dire una cosa nella prima frase e il contrario subito dopo... ottimo direi.

[evil weasel]

Non è che in ogni caso fosse particolarmente complesso attivarlo a mano.

[floc]

per un utente medio di ubuntu si', e' complicatissimo attivarlo a mano probabilmente e' quello il vero problema, piu' che il "ritardo" di ubuntu

[s12a]

Non è un problema di Canonical, ma di Linux in generale in questo ambito.

Il supporto al trim (sia in real time che a livello di partizione, almeno su ext4 e qualche altro FS, ma meno diffuso) c'è ma per motivi dipendenti da incompatibilità e problemi passati è disabilitato di default. Purtroppo qui mi viene spontanea una battuta cattiva: probabilmente non è mai interessato molto cambiare la situazione perché l'utenza media tende ad usare le varie distribuzioni con hardware vecchio od obsoleto. Vedendo ancora guide in giro per Linux che consigliano interventi allucinanti come ad esempio disabilitare il journaling del file system per "salvaguardare l'SSD", direi che manca la cultura a riguardo. Senza fare nulla, a parità d'uso le scritture effettuate dall'OS sono abbastanza inferiori che con Windows 7/8. Se già con Windows non serve fare nulla, a maggior ragione, a patto che il trim sia abilitato, non serve su Linux.

Originariamente inviato da lucreghert

Bhè...Considerato che tutti gli attuali SSD venduti hanno al loro interno un controller che si occupa di liberare la cella non più utilizzata,direi che non serve a una bella ceppa di nulla affidare questo compito al sistema operativo.
Io sul mio SSD il trim non l'ho mai attivato e secondo i miei test le prestazioni rispetto a quando era nuovo non sono cambiate di una virgola.

In lettura cambia poco o nulla, ma in scrittura la situazione cambia eccome. Incidentalmente nel thread degli SSD pochi minuti fa avevo scritto un post a riguardo, con tanto di test:

http://www.hwupgrade.it/forum/showth...2#post40456332

Fra le altre cose usare il trim spesso segnalando all'SSD quali settori logici sono effettivamente liberi diminuisce l'usura delle sue memorie a lungo termine, oltre che le prestazioni in scrittura sul breve.

[Freaxxx]

si dovrebbero scusare per ben altro, questa distribuzione era interessante ed aveva preso una bella piega ai tempi di Hardy Heron, adesso è un guazzabuglio di software sparso senza capo ne coda.
La politica di Canonical è diventata criptica a dir poco, il software ha una architettura che sembra un arcimboldo, il futuro è un " si, forse, magari, tra poco arriva ma forse anche no " ( vedi MIR vs Wayland che se continua così mi sa che X dura per altri 10 anni, tanto Intel ha gia abbandonato il support per MIR ).

Al prossimo computer mi scelgo ben bene l'hardware per stare con Debian il più possibile, purtroppo non posso usare ne la testing ne sid perché sono versioni o troppo aggiornate o senza support ai driver che mi interessano, e la debian stabile contiene pacchetti troppo vecchi; ma per il resto, mai avuto un problema con Debian quando l'avevo come desktop principale.

Meglio perderli che trovarli i "prodotti" di Canonical.

[lucreghert]

Originariamente inviato da s12a

In lettura cambia poco o nulla, ma in scrittura la situazione cambia eccome. Incidentalmente nel thread degli SSD pochi minuti fa avevo scritto un post a riguardo, con tanto di test:

http://www.hwupgrade.it/forum/showth...2#post40456332

Fra le altre cose usare il trim spesso segnalando all'SSD quali settori logici sono effettivamente liberi diminuisce l'usura delle sue memorie a lungo termine, oltre che le prestazioni in scrittura sul breve.

Non sono i test che mi fanno strappare i capelli dalla disperazione.
Nell'uso quotidiano non te ne accorgi neanche rispetto a quando era nuovo per cui il discorso non fa una piega.

[s12a]

Non sono tanto i valori massimi nel benchmark (insomma...), quanto, nella pratica, il fatto che più l'SSD è pieno più il wear leveling sarà intenso quando si andrà usare l'SSD in scrittura. Questo aumenta i tempi di risposta dello stesso e può causare effetti di stuttering avvertibili se si stanno leggendo dati in streaming (video, audio, ecc) in contemporanea. Senza contare che come detto si aumenta inutilmente la write amplification e quindi l'usura del drive.

Non c'è veramente alcun motivo reale per non usare il trim qualora sia disponibile, a parte esigenze molto specifiche o problemi in merito.

[dpcris85]

Commenterò con solo 4 parole:"Windows XP su SATA"

[dobermann77]

Originariamente inviato da dpcris85

Commenterò con solo 4 parole:"Windows XP su SATA"

Uh?

[aald213]

Originariamente inviato da lucreghert

Bhè...Considerato che tutti gli attuali SSD venduti hanno al loro interno un controller che si occupa di liberare la cella non più utilizzata,direi che non serve a una bella ceppa di nulla affidare questo compito al sistema operativo.

Informati! Il supporto del sistema operativo/file system è fondamentale, perché il controller non può sapere se i dati scritti sono cancellabili o meno.

[aald213]

Originariamente inviato da Freaxxx

si dovrebbero scusare per ben altro, questa distribuzione era interessante ed aveva preso una bella piega ai tempi di Hardy Heron, adesso è un guazzabuglio di software sparso senza capo ne coda.
La politica di Canonical è diventata criptica a dir poco, il software ha una architettura che sembra un arcimboldo, il futuro è un " si, forse, magari, tra poco arriva ma forse anche no " ( vedi MIR vs Wayland che se continua così mi sa che X dura per altri 10 anni, tanto Intel ha gia abbandonato il support per MIR ).

Al prossimo computer mi scelgo ben bene l'hardware per stare con Debian il più possibile, purtroppo non posso usare ne la testing ne sid perché sono versioni o troppo aggiornate o senza support ai driver che mi interessano, e la debian stabile contiene pacchetti troppo vecchi; ma per il resto, mai avuto un problema con Debian quando l'avevo come desktop principale.

Meglio perderli che trovarli i "prodotti" di Canonical.

Ma che c'entra tutto questo con l'articolo? Di troll ce n'è già abbastanza.

[aald213]

Originariamente inviato da Cloud76

uh, già dalla prossima release, bene sono in anticipo...

ah no, allora sono in ritardo spaventoso...

Ecco... come dire una cosa nella prima frase e il contrario subito dopo... ottimo direi.

In passato, e possibilmente anche adesso, il trimming realtime aveva dei casi in cui le prestazioni diminuivano (se non sbaglio, la cancellazione di massa di file), tant'è che suggerivano di schedularlo a intervalli di tempo predefinito.

Evidentemente il supporto è maturato solo adesso, oppure hanno deciso che i vantaggi complessivamente superano gli svantaggi.

[dobermann77]

Originariamente inviato da aald213

Evidentemente il supporto è maturato solo adesso, oppure hanno deciso che i vantaggi complessivamente superano gli svantaggi.

Purche' non ci sia il rischio di perdere dati...

[s12a]

Originariamente inviato da aald213

In passato, e possibilmente anche adesso, il trimming realtime aveva dei casi in cui le prestazioni diminuivano (se non sbaglio, la cancellazione di massa di file), tant'è che suggerivano di schedularlo a intervalli di tempo predefinito.

Evidentemente il supporto è maturato solo adesso, oppure hanno deciso che i vantaggi complessivamente superano gli svantaggi.

C'è principalmente la maturazione degli SSD e del loro supporto in generale dal punto di vista dei controller delle schede madri, oltre che probabilmente l'oramai maturazione del tempo di rodaggio di questa funzionalità (mi sembra che agli inizi del supporto ci fossero bug più o meno serii).

Da una parte con l'ultima revisione 3.1 delle specifiche SATA introdotta nel 2011, si introduce il queued trim. Questo verrà introdotto a partire dal kernel Linux 3.12, tuttavia.

Dall'altra gli ultimi SSD già di loro non prendono il comando trim come un ordine, ma solo come un suggerimento, ed è a loro discrezione eseguirlo o meno ed in quale momento.
Non ho link a portata di click (perciò mi scuso se tutto suona un po' vago) ma tempo fa ho letto un aneddoto di uno sviluppatore del kernel Linux che riportava che a seguito di discussioni private con un ingegnere di uno dei principali produttori di SSD nelle quali suggeriva di inviare il comando trim "spesso e volentieri" qualora se ne presenti la necessità (dato che ci pensa il controller dell'SSD a gestirsi le richieste), se non fosse alla fine essenzialmente inutile/poco produttivo prodigarsi per implementare complessi algoritmi di gestione del comando trim dal punto di vista del file system come sembra fare Windows.

EDIT (appena prima di inviare il messaggio): qui http://markmail.org/message/wlhgr3wpfpbtbkmm