Link alla notizia: http://www.hwfiles.it/news/ubuntu-supporto-a-trim-abilitato-di-default-dalla-1404_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.

Sulle ultime versioni di OpenSuse va attivato manualmente?

Alla buon'ora...

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.

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.:D

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

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.
:confused:

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.

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

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

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.

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. :D
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/showthread.php?p=40456332#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.

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.

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/showthread.php?p=40456332#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.

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.

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

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

Uh? :eek:

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.

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.

:confused:


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.

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...

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

In passato, ... CUT...

O hai sbagliato il quote o non hai capito il mio intervento.

Io ho solo quotato le prime frasi dell'articolo, in cui l'autore nella prima frase dice una cosa e subito dopo dice l'esatto contrario.
Tanto per cambiare...

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

quindi? il controller potrebbe impedire al SO di eseguire il trim, e per quale motivo visto che dai test che hai riportato il trim velocizza i tempi di scrittura oltre a usurare meno gli SSD nel tempo?
Mi sembra un controsenso a prescindere dal sistema operativo..

quindi? il controller potrebbe impedire al SO di eseguire il trim, e per quale motivo visto che dai test che hai riportato il trim velocizza i tempi di scrittura oltre a usurare meno gli SSD nel tempo?
Mi sembra un controsenso a prescindere dal sistema operativo..
Il senso è che già ora (a prescindere dal queued trim che fa parte delle nuove specifiche SATA), durante l'uso attivo dell'SSD da parte dell'utente, il controller dell'SSD può decidere di rimandare l'esecuzione del trim (o non eseguirlo affatto se non necessario) affinché non ci siano potenziali cali prestazionali a brevissimo termine dovuti alla sua invocazione.

Detto praticamente, su Linux con il flag di mount discard abilitato, ad ogni cancellazione di file segue immediatamente l'invio del comando trim sui settori logici ad essi corrispondenti. Con alcuni SSD, cancellare un numero notevole di file poteva dunque essere un'operazione lenta, perché la richiesta dell'OS veniva onorata immediatamente per ciascun file. Con gli SSD di concezione più recente invece no, o comunque non necessariamente.

cosa significa 'abilitato di default' ?
aggiunge automaticamente il parametro 'discard' nell'fstab,
oppure viene utilizzato fstrim?

Mi sembrava di aver letto tempo fa che la cosa sarebbe stata implementata con l'uso automatico di fstrim ad intervalli regolari.

EDIT: http://www.webupd8.org/2013/12/trim-enabled-by-default-for-ssds-on.html

...At UDS there was a discussion about the method that was going to be used for trimming: online discard (adding a "discard" option to /etc/fstab) or fstrim with a cron job. Based on some benchmarks, the developers decided to go with fstrim because, like we also pointed out a while back, with online discard there's a performance hit, for example when deleting a large number of small files...

Ancora una volta le distro GNU/Linux arrivano in ritardo rispetto ad altri sistemi operativi.

Comunque, alla buon ora.

già sembrerebbe più un fstrim che un discard...avevo letto anch'io diversi articoli
dove dicevano che il discard rallentava nelle cancellazioni. In realtà sono ugualmente lenti (o veloci). L'operazione è la medesima. Con fstrim semplicemente aggreghi e rimandi l'operazione ad un momento [pianificato] meno critico. Io in ogni caso con i miei SSD Samsung 830 e 840 non ho mai avvertito rallentamenti dovuti al suo uso, anche forzandolo (su Windows) con il tool del produttore che bypassa il supporto al trim del sistema operativo. Sono pronto a scommettere che a dare problemi sono stati i primi controller Indilinx e Sandforce con supporto al trim ed evidentemente dato che nessuno fin'ora ha avuto voglia di implementare uno scheduler dedicato per evitare problemi con essi (o altri controller problematici/meno sofisticati), il trim su Linux è sempre rimasto disabilitato di default.

Ma il bello di linux è che non sei obbligato a seguire una strada...alla fine puoi fare come ti pare (assumendoti ovviamente le responsabilità del caso) :)
Su Windows 8 è stato introdotto il comando defrag /L che è più o meno l'equivalente di fstrim su Linux.

non lo sapevo, ma quindi c'è anche un comando per abilitare/disabilitare il trim simile
a discard?

Certo, con il comando, da terminale con privilegi elevati:

fsutil behavior set disabledeletenotify 1

Non so quanto conveniente sia la cosa dato che il trim in real time su Windows funziona in maniera abbastanza sofisticata (ossia: bene).

non mi aspettavo un commento del genere da chi sfoggia Arch in firma.
Il supporto a trim, come ben saprai, è presente da tempo, sta a l'utente la facoltà di abilitarlo oppure di usare altri metodi. Se preferisci le imposizioni ci sono già
delle ottime alternative, per di più a pagamento. :)

Addirittura "imposizioni"?

Si tratta di una scelta logica perché è un meccanismo che consente di aumentare le prestazioni in scrittura su SSD.

Dopodiché da quanto tempo sono in commercio gli SSD? La mia considerazione è dovuta a questo fatto.

Windows 7 supporta nativamente quel comando e lo abilita di default qual'ora rilevi unità SSD. Ed è uscito nel 2009.

http://en.wikipedia.org/wiki/Features_new_to_Windows_7#Solid_state_drives

La "facoltà" di abilitarlo o meno è dovuto al fatto che non era una feature collaudata, ovvero nessuno si è preso la responsabilità (non è una novità del resto in questo ambito) di abilitarlo di default.

Ovviamente l'utente smaliziato lo sa, ma la stragrande maggioranza no.

Mi pare che anche negli ultimi Android sia stata attivata questa funzionalità da poco (forse proprio dall'ultima versione, 4.4).

Dopodiché io baso le mie considerazioni sul carattere tecnico. Ci hanno sempre raccontato che i sistemi *nix godevano di una certa superiorità tecnica, non è questo il caso.

beh fai il contrario.....
lo abiliti di default così l'utente comune non ha alcun problema e quello smaliziato come si documenta per attivarlo lo fa per disattivarlo

poi ci sono tante di quelle distribuzioni con cui incasinarsi che di certo non manca lo spazio per non essere banali :D

@WarDuck

imposizioni nel senso che, da quello che ho letto in giro, il trim non è sempre necessario,
e quindi può avere un senso il fatto che non sia abilitato di default.

ti riporto una frase da debian wiki (che presumo sia una fonte abbastanza autorevole):
"The "discard" options is not needed if your SSD has enough overprovisioning (spare space) or you leave (unpartitioned) free space on the SSD. "


Non mi sembra una soluzione, e neanche una scusa valida onestamente.

Cioè come dire, non hai bisogno di raccolta differenziata fin tanto che non vedi la spazzatura in giro per le strade.

E' un modo di ragionare un po' troppo superficiale.


Che poi,per l'utente comune, sia una comodità averlo abilitato di default, sono d'ccordo con te, però stiamo parlando di linux...mi pare che l'informatica sia stata già abbastanza
banalizzata in nome della 'semplicità'. Lo vogliamo lasciare un piccolo angolino
dove le persone siano 'costrette' a far lavorare i neuroni e vengano incoraggiate
a capire ciò che stanno facendo? :)

Non solo per l'utente comune, ma anche per quello esperto, perché non tutti sono disposti a perdere tempo per impostare dettagli di basso livello che dovrebbero essere scontati (o quasi).

D'altro canto quello che dici può essere vero in generale, ma ha ben poco senso in questo caso.

Nel passato ci sono stati casi simili (automount USB, modem USB, wireless, power management)...

Il fatto che uno usa GNU/Linux mica vuol dire necessariamente che deve perdere tempo e sarebbe ora che la community si svegliasse perché non siamo più negli anni 80.

Dopodiché "banalizzare" ha un significato decisamente negativo rispetto a "semplificare" che è il termine più adatto.

Il punto è che i vari sistemi sono nati con scopi ben diversi l'uno dall'altro, ed entrambi tentano di mitigare i propri punti deboli, chi più chi meno.

Ovviamente a me piace discutere nel merito delle cose, e quindi del COME lo stanno facendo.

Dopodiché ripeto, il mio è un appunto del tutto tecnico, poi lascio a chi legge i giudizi del caso.

...
Il fatto che uno usa GNU/Linux mica vuol dire necessariamente che deve perdere tempo e sarebbe ora che la community si svegliasse perché non siamo più negli anni 80...
concordo. :)