[Nuova guida] SSD e TRIM su Ubuntu

[emanuc]

compress=zstd:1 e compress=lzo (btrfs): per informazioni consultare questa guida.

Qui metterei semplicemente:
Compressione (btrfs): per informazioni consultare questa guida.
O se dobbiamo specificare almeno un opzione di mount, lascerei solo zstd (per chi vuole approfondire segue il link alla guida):
compress=zstd:1 (btrfs): per informazioni consultare questa guida.

[xavier77]

Allora, se non ci sono pareri contrari, sarei per rinominare e pubblicare la guida andreas-xavier/OttimizzareSSD. Si tratta di una guida nuova che non dovrebbe "stonare" con il resto della documentazione (ci sarebbero solo alcune ridondanze - temporanee - con la guida sul Trim).

Mentre per quanto riguarda andreas-xavier/ProvaTrim, aspetterei un altro po' (magari non troppi giorni) per fare il copia/incolla in Hardware/Dispositivi Partizioni/Trim...
OK?

[wilecoyote]

) Salve, complessivamente mi pare buona la wiki sui SSD, però visto che chiedi un'opinione vi provvedo su 4 punti che mi paiono rilevanti.

1) Non sempre è impostabile il Bios ad AHCI, manca proprio la voce, ergo come è resta.
2) Sconsigliare d'evitare la deframmentazione in Window non mi pare un granché, recentemente ho dovuto chiedere aiuto per un 10 piantato per questa problematica, che piantava l'avvio tout court di tutti i 3 sistemi installati.
3) Fra le pratiche sconsigliate aggiungerei di Non usare i SSD per installare e provare compulsivamente nuove distro Linux, consigliando di limitarsi per le prove alle Live, magari con Ventoy et simila.
4) Infine la mia cronica fissa peraltro già espressa, manca la discussione di supporto dedicata.

:: Ciao

[xavier77]

) Salve, complessivamente mi pare buona la wiki sui SSD, però visto che chiedi un'opinione vi provvedo su 4 punti che mi paiono rilevanti.

1) Non sempre è impostabile il Bios ad AHCI, manca proprio la voce, ergo come è resta.
2) Sconsigliare d'evitare la deframmentazione in Window non mi pare un granché, recentemente ho dovuto chiedere aiuto per un 10 piantato per questa problematica, che piantava l'avvio tout court di tutti i 3 sistemi installati.
3) Fra le pratiche sconsigliate aggiungerei di Non usare i SSD per installare e provare compulsivamente nuove distro Linux, consigliando di limitarsi per le prove alle Live, magari con Ventoy et simila.
4) Infine la mia cronica fissa peraltro già espressa, manca la discussione di supporto dedicata.

1. Siccome i BIOS non sono tutti uguali c'è scritto di consultare in ogni caso le istruzioni per la propria scheda madre.
2. Deframmentare con l'ssd??????? Ma assolutamente no! https://www.makeuseof.com/should-you-defrag-an-ssd/
3. Mi sembra più che superfluo.
4. Ti avevo già risposto.

EDIT: @wilecoyote in seguito alla tua osservazione ho modificato così la parte relativa a AHCI:
«nelle impostazioni SATA assicurarsi che sia impostata la modalità AHCI e non IDE. A seconda dei modelli l'opzione potrebbe essere denominata diversamente oppure essere assente (ad esempio perché abilitata di default nei BIOS più recenti). In caso di dubbi fare riferimento alle istruzioni della propria scheda madre».

PS: l'unica parte che avrei voluto più breve è il punto relativo ai backup. Ma per forza di cose alcuni argomenti hanno bisogno di un minimo di approfondimento tecnico. In più sono pochissimi i casi in cui ho sentito di SSD rotti, mai per esperienza diretta. Comunque quando si tratta di sicurezza dei dati - si sa - meglio la paranoia del danno...

[frapox]

) Salve, complessivamente mi pare buona la wiki sui SSD, però visto che chiedi un'opinione vi provvedo su 4 punti che mi paiono rilevanti.

1) Non sempre è impostabile il Bios ad AHCI, manca proprio la voce, ergo come è resta.
2) Sconsigliare d'evitare la deframmentazione in Window non mi pare un granché, recentemente ho dovuto chiedere aiuto per un 10 piantato per questa problematica, che piantava l'avvio tout court di tutti i 3 sistemi installati.
3) Fra le pratiche sconsigliate aggiungerei di Non usare i SSD per installare e provare compulsivamente nuove distro Linux, consigliando di limitarsi per le prove alle Live, magari con Ventoy et simila.
4) Infine la mia cronica fissa peraltro già espressa, manca la discussione di supporto dedicata.

:: Ciao

2. Deframmentare con l'ssd??????? Ma assolutamente no! https://www.makeuseof.com/should-you-defrag-an-ssd/

Giriamola in modo da renderla più chiara: consigliare di deframmentare un SSD è un atto criminale. Oltre a non portare alcun beneficio, ammazza la durata delle celle, molto più che fare il tester compulsivo di distro.

PS. è Windows, non Window.

[xavier77]

Come anticipato, pubblicata Hardware/DispositiviPartizioni/OttimizzareSSD.
A breve revisione della guida specifica per il TRIM.

[ivantu]

Per quanto riguarda le mie verifiche, avendo comprato tempo fa un ssd Samsung, e fatto nuove partizioni /, in pratica, senza che facessi nulla, mi sono ritrovato con in automatico le voci adiacente in /etc/fstab come da guida stessa. Discard, ecc..
Quindi non so, se sia deprecata, o in tal altro modo come te @xavier77, l'hai definita. Se è deprecata, perché?, ti chiedo.

Sinceramente - andando a memoria - negli ultimi anni non ho mai trovato in /etc/fstab l'opzione discard abilitata da sola. Almeno nelle mie installazioni.
Però se conoscete altri casi fate sapere, così almeno abbiamo un quadro più completo.
(Per la cronaca: mi è capitato invece che venisse impostato da solo noatime.)
Perché l'opzione discard sia sconsigliata è scritto già negli interventi sopra. Ed è anche indicata come procedura non raccomandata nel documento originale della guida attuale che hai revisionato (datato ben 2013!). Vedi anche Documentazione di Red Hat: «Note that it is currently recommended to use fstrim application to discard unused blocks rather than the discard mount option because the performance impact of this option can be quite severe. For this reason, nodiscard is the default».
Il perché è presto detto: come scritto anche nella wiki di Arch quell'opzione esegue un trim continuo (ed "online", cioè con il sistema avviato ed in funzione), impegnando il sistema inutilmente (quando tutti dicono che basta eseguire il trim una volta a settimana, o al massimo una volta al giorno).

NB: tutte le procedure riportate nella guida attuale, che hai revisionato, sono ancora tutte praticabili e funzionanti. Non sono però al passo con i tempi, (se scorri la discussione vedrai che ce ne eravamo accorti già alcuni anni fa). Non mi dilungo oltre perché tutte le informazioni per approfondire sono contenute in questa discussione e nelle stesse pagine di prova (ma se fai una ricerca su Internet troverai conferma sa parecchie fonti in pochi minuti).

Attenzione che l'async discard su Btrfs è supportato solo dalla versione 5.6 del kernel (quindi escluso il kernel "stock" di Focal, per esempio) e inoltre, seppur più efficiente, è comunque un'operazione che degrada le prestazioni a fronte di un vantaggio sostanzialment nullo (su per un uso desktop) quindi non so se val la pena di menzionarlo.

In realtà tutto quel paragrafo è marcato come facoltativo. Però ho specificato meglio le info da te fornite

ti confermo che sulla mia installazione di Jammy non ho dovuto eseguire i passaggi 1,2 e 3 della sezione "Partizioni criptate"; semplicemente è sufficiente inserire la partizione-container da aprire nel file /etc/crypttab e poi aggiornare l'initramfs, compresa eventualmente la partizione che contiene root (che viene montata dallo script /scripts/local-top nell'initramfs).

Va be, le partizioni criptate è un altro argomento di cui sono poco pratico.
Provo anche a documentarmi e magari aspettiamo anche l'eventuale contributo di altri.
Grazie intanto

EDIT: per il momento sto consultando alcune fonti fra cui https://wiki.archlinux.org/title/Dm-cry ... ives_(SSD)
Ci sarebbero alcune implicazioni per la sicurezza dei dati crittografati. Da capire poi, nel concreto, se effettive oppure se solamente potenziali...

Chi ha detto che i casi nelle tue installazioni sono maggioritarie? Sono spesso affrontate? Non mi sembrano do vedere casi uguali.

mi ricordi, che tu sia un chiodo senza il martello.
Uno degli errori che poni più spesso, è quello di vedere cose come vuoi soltanto tu, e non come sono davvero.
@xavier77 Finiscila per piacere....

[frapox]

EDIT: per il momento sto consultando alcune fonti fra cui https://wiki.archlinux.org/title/Dm-cry ... ives_(SSD)
Ci sarebbero alcune implicazioni per la sicurezza dei dati crittografati. Da capire poi, nel concreto, se effettive oppure se solamente potenziali...

Ho visto solo adesso questo "edit".

Sì è vero quello che ci sono implicazioni per la sicurezza, che ho preso in considerazione a suo tempo, comunque:
- riguardano solo il tipo di filesystem contenuto nel container criptato (non i file contenuti)
- riguardano l'eventuale volume di tipo "nascosto" presente nella partizione (un caso non così frequente)

Per tutto il resto, cioè credo per una buona fetta di utenza a cui interessa solo nascondere i file e non nascondere il fatto che sta nascondendo i file, queste "implicazioni" sono abbastanza o del tutto irrisorie.

[frapox]

Per quanto riguarda le mie verifiche, avendo comprato tempo fa un ssd Samsung, e fatto nuove partizioni /, in pratica, senza che facessi nulla, mi sono ritrovato con in automatico le voci adiacente in /etc/fstab come da guida stessa. Discard, ecc..
Quindi non so, se sia deprecata, o in tal altro modo come te @xavier77, l'hai definita. Se è deprecata, perché?, ti chiedo.

Sinceramente - andando a memoria - negli ultimi anni non ho mai trovato in /etc/fstab l'opzione discard abilitata da sola. Almeno nelle mie installazioni.
Però se conoscete altri casi fate sapere, così almeno abbiamo un quadro più completo.
(Per la cronaca: mi è capitato invece che venisse impostato da solo noatime.)
Perché l'opzione discard sia sconsigliata è scritto già negli interventi sopra. Ed è anche indicata come procedura non raccomandata nel documento originale della guida attuale che hai revisionato (datato ben 2013!). Vedi anche Documentazione di Red Hat: «Note that it is currently recommended to use fstrim application to discard unused blocks rather than the discard mount option because the performance impact of this option can be quite severe. For this reason, nodiscard is the default».
Il perché è presto detto: come scritto anche nella wiki di Arch quell'opzione esegue un trim continuo (ed "online", cioè con il sistema avviato ed in funzione), impegnando il sistema inutilmente (quando tutti dicono che basta eseguire il trim una volta a settimana, o al massimo una volta al giorno).

NB: tutte le procedure riportate nella guida attuale, che hai revisionato, sono ancora tutte praticabili e funzionanti. Non sono però al passo con i tempi, (se scorri la discussione vedrai che ce ne eravamo accorti già alcuni anni fa). Non mi dilungo oltre perché tutte le informazioni per approfondire sono contenute in questa discussione e nelle stesse pagine di prova (ma se fai una ricerca su Internet troverai conferma sa parecchie fonti in pochi minuti).

Attenzione che l'async discard su Btrfs è supportato solo dalla versione 5.6 del kernel (quindi escluso il kernel "stock" di Focal, per esempio) e inoltre, seppur più efficiente, è comunque un'operazione che degrada le prestazioni a fronte di un vantaggio sostanzialment nullo (su per un uso desktop) quindi non so se val la pena di menzionarlo.

In realtà tutto quel paragrafo è marcato come facoltativo. Però ho specificato meglio le info da te fornite

ti confermo che sulla mia installazione di Jammy non ho dovuto eseguire i passaggi 1,2 e 3 della sezione "Partizioni criptate"; semplicemente è sufficiente inserire la partizione-container da aprire nel file /etc/crypttab e poi aggiornare l'initramfs, compresa eventualmente la partizione che contiene root (che viene montata dallo script /scripts/local-top nell'initramfs).

Va be, le partizioni criptate è un altro argomento di cui sono poco pratico.
Provo anche a documentarmi e magari aspettiamo anche l'eventuale contributo di altri.
Grazie intanto

EDIT: per il momento sto consultando alcune fonti fra cui https://wiki.archlinux.org/title/Dm-cry ... ives_(SSD)
Ci sarebbero alcune implicazioni per la sicurezza dei dati crittografati. Da capire poi, nel concreto, se effettive oppure se solamente potenziali...

Chi ha detto che i casi nelle tue installazioni sono maggioritarie? Sono spesso affrontate? Non mi sembrano do vedere casi uguali.

mi ricordi, che tu sia un chiodo senza il martello.
Uno degli errori che poni più spesso, è quello di vedere cose come vuoi soltanto tu, e non come sono davvero.
@xavier77 Finiscila per piacere....

Ma di cosa stai parlando? Se ti riferisci al discard (e allora magari quota solo quella parte) xavier ha ragione, e ti ha riportato ben due fonti autorevoli che spiegano (se ce ne fosse il bisogno) che il discard come opzione di mount non si utilizza perchè (come avevo detto anch'io) penalizza le prestazioni in modo considerevole a fronte di nessun vantaggio. L'opzione discard non la usa più nessuno, né tanto meno è impostata di default su una nuova install di ubuntu (o di qualsiasi altra distro), e infatti viene sconsigliata sia da Red Hat sia da Arch.

[xavier77]

Chi ha detto che i casi nelle tue installazioni sono maggioritarie? Sono spesso affrontate? Non mi sembrano do vedere casi uguali.
mi ricordi, che tu sia un chiodo senza il martello.
Uno degli errori che poni più spesso, è quello di vedere cose come vuoi soltanto tu, e non come sono davvero.
@xavier77 Finiscila per piacere....

Riguardo al trim tramite opzione discard ti ho già risposto.
Per favore, cerchiamo di rimanere sul tecnico, senza metterla sul personale (con argomentazioni che non stanno neanche in piedi, ma va be'...).

EDIT: ti ha risposto anche frapox... non aggiungo altro.

EDIT: per il momento sto consultando alcune fonti fra cui https://wiki.archlinux.org/title/Dm-cry ... ives_(SSD)
Ci sarebbero alcune implicazioni per la sicurezza dei dati crittografati. Da capire poi, nel concreto, se effettive oppure se solamente potenziali...

Ho visto solo adesso questo "edit".

Sì è vero quello che ci sono implicazioni per la sicurezza, che ho preso in considerazione a suo tempo, comunque:
- riguardano solo il tipo di filesystem contenuto nel container criptato (non i file contenuti)
- riguardano l'eventuale volume di tipo "nascosto" presente nella partizione (un caso non così frequente)

Per tutto il resto, cioè credo per una buona fetta di utenza a cui interessa solo nascondere i file e non nascondere il fatto che sta nascondendo i file, queste "implicazioni" sono abbastanza o del tutto irrisorie.

Va be allora lascio il paragrafo com'è, OK?

[ivantu]

Con quali strumenti avete fatto i test?

Con quali .iso, avete fatto i test?
Con quali installazioni *Ubuntu, avete fatto i test?

Con Lubuntu? Con Kubuntu? ci avete provato? credo estremamente di No.
Se non provate l'esperienza, di che cosa ne sapete?

Inutile negare quello che vi dico.

[frapox]

Va be allora lascio il paragrafo com'è, OK?

Per me può andare. Come ti facevo notare qualche post addietro, i punti 1 2 3 risultano superflui almeno sulla 22.04 e quasi certamente sulla 20.04, sulla 18.04 non ho idea.

Comunque, ma penso lo saprai già, la guida sul Trim non è sincronizzata con quella sull'ottimizzareSSD in quanto, per esempio:
- l'opzione di mount discard viene data come prima opzione quando nell'altra guida viene invece (giustamente) sconsigliata
- il cronjob giornaliero, dato che esiste il timer di systemd settimanale, come giustamente riportato nella seconda
- nella sezione Ottimizzazione del TRIM anche lì si fa riferimento solo al cronjob e non al timer systemd
- la frase "Disattivare la partizione di swap se si hanno a disposizione più di 4GB di RAM oppure di utilizzarla su un altro disco rigido interno, se presente." mi pare abbastanza di dubbia utilità sopratutto se riferita al Trim.
- più o meno lo stesso discorso sul Preload e Prelink, non vedo in che modo possano avere attinenza col Trim.

Con quali strumenti avete fatto i test?

Con quali .iso, avete fatto i test?
Con quali installazioni *Ubuntu, avete fatto i test?

Con Lubuntu? Con Kubuntu? ci avete provato? credo estremamente di No.
Se non provate l'esperienza, di che cosa ne sapete?

Inutile negare quello che vi dico.

Ti rispondo sul tecnico come vuole xavier (anche se la tentazione di risponderti "a tono" sarebbe forte):
1- Xubuntu, Lubuntu, etc. sono tutte la stessa cosa (la base è uguale) quindi la distinzione in derivate è inutile, a meno che si stia parlando di Desktop environment, ma non è questo il caso.
2- Gli "strumenti" con cui ho fatto i test sono svariate distro dal 2018 in avanti (cioè da quando ho un SSD), non solo Ubuntu. Mai dovuto usare il parametro discard perché tutte ormai si appoggiano a fstrim. Quindi è inutile.
3- L'esperienza serve se è coadiuvata da una base teorica, altrimenti l' "esperienza" è del tutto inutile. Tutte le wiki del mondo e i post in giro per i forum sono concordi che il discard come mount option è deleteria più che utile, da cui il "nostro" sapere. Hai bisogno di altre conferme? Altrimenti anche questa obiezione è inutile, come le altre che hai fatto.

[xavier77]

Va be allora lascio il paragrafo com'è, OK?

Per me può andare. Come ti facevo notare qualche post addietro, i punti 1 2 3 risultano superflui almeno sulla 22.04 e quasi certamente sulla 20.04, sulla 18.04 non ho idea.

Comunque, ma penso lo saprai già, la guida sul Trim non è sincronizzata con quella sull'ottimizzareSSD in quanto, per esempio:
- l'opzione di mount discard viene data come prima opzione quando nell'altra guida viene invece (giustamente) sconsigliata
- il cronjob giornaliero, dato che esiste il timer di systemd settimanale, come giustamente riportato nella seconda
- nella sezione Ottimizzazione del TRIM anche lì si fa riferimento solo al cronjob e non al timer systemd
- la frase "Disattivare la partizione di swap se si hanno a disposizione più di 4GB di RAM oppure di utilizzarla su un altro disco rigido interno, se presente." mi pare abbastanza di dubbia utilità sopratutto se riferita al Trim.
- più o meno lo stesso discorso sul Preload e Prelink, non vedo in che modo possano avere attinenza col Trim.

emh... ho paura che stia leggendo la pagina attuale.
Devi vedere se va bene la pagina di prova:
andreas-xavier/ProvaTrim

Con quali strumenti avete fatto i test?
Con quali .iso, avete fatto i test?
Con quali installazioni *Ubuntu, avete fatto i test?
Con Lubuntu? Con Kubuntu? ci avete provato? credo estremamente di No.
Se non provate l'esperienza, di che cosa ne sapete?
Inutile negare quello che vi dico.

Alla risposta sopra di frapox aggiungo solo che per verificare presenza e frequenza del servizio relativo al ftrim, GB sottoposti a trim, log ecc. basta consultare la pagina di prova stessa.
Inoltre, vale la pena "stressare" sistema ed SSD con discard (=trim continuo) quando quelli attuali sono già costruiti per resistere a scritture massive???

Spoiler

Mostra

esempio già vecchio di alcuni anni: si stima che SSD con MLC possono tollerare 3000-5000; sottostimando a 3000, un SSD da 128 GB con scritture giornaliere da 10 GB funzionerà 38000 giorni, ossia 100 anni...

Inoltre se per "eseguire test" intendi limitarsi a controllare se i comandi funzionano ancora, già ti dissi:

NB: tutte le procedure riportate nella guida attuale, che hai revisionato, sono ancora tutte praticabili e funzionanti. Non sono però al passo con i tempi, (se scorri la discussione vedrai che ce ne eravamo accorti già alcuni anni fa). Non mi dilungo oltre perché tutte le informazioni per approfondire sono contenute in questa discussione e nelle stesse pagine di prova (ma se fai una ricerca su Internet troverai conferma sa parecchie fonti in pochi minuti).

Capisco che ti sia impegnato a revisionare la pagina, ma non possiamo mantenere nella doc indicazioni che risultavano obsolete già sette anni fa (scorri indietro la discussione).
Infine, oltre ad eseguire test ti consiglio di perdere qualche giorno a leggere documentazioni in inglese, wiki di varie distro, mailinglist, bugzilla vari ecc. ecc. come ho fatto io.

[frapox]

Erano istruzioni vecchie già 11 anni fa:

L'implementazione del kernel di realtime trim (trim in tempo reale) in 11.2, 11.3, e 11.4 non è ottimizzata. Le specifiche richiedono per supportare trim una lista vettorizzata di intervalli di settori a cui applicare trim, ma, fino al kernel 3.0, trim è soltanto invocato dal kernel con un singolo intervallo di blocchi da scaricare (ovvero a cui applicare discard / trim) e con le attuali unità SSD di metà del 2011 è stato appurato che ciò causa un degrado delle prestazioni invece che un aumento delle stesse. Esistono poche ragioni per sfruttare il supporto del kernel a realtime discard con le versioni del kernel precedenti la 3.1. Non è noto quando la funzionalità di discard del kernel verrà ottimizzata in modo tale da funzionare efficacemente con la generazione corrente di unità SSD.

(wiki di Opensuse)

emh... ho paura che stia leggendo la pagina attuale.
Devi vedere se va bene la pagina di prova:
andreas-xavier/ProvaTrim

Si stavo guardando la pagina attuale. Nella tua bozza mi pare che hai sistemato tutti i punti di cui sopra, per me va bene.

[wilecoyote]

) Salve,

) Salve, complessivamente mi pare buona la wiki sui SSD, però visto che chiedi un'opinione vi provvedo su 4 punti che mi paiono rilevanti.

1) Non sempre è impostabile il Bios ad AHCI, manca proprio la voce, ergo come è resta.
2) Sconsigliare d'evitare la deframmentazione in Window non mi pare un granché, recentemente ho dovuto chiedere aiuto per un 10 piantato per questa problematica, che piantava l'avvio tout court di tutti i 3 sistemi installati.
3) Fra le pratiche sconsigliate aggiungerei di Non usare i SSD per installare e provare compulsivamente nuove distro Linux, consigliando di limitarsi per le prove alle Live, magari con Ventoy et simila.
4) Infine la mia cronica fissa peraltro già espressa, manca la discussione di supporto dedicata.

1. Siccome i BIOS non sono tutti uguali c'è scritto di consultare in ogni caso le istruzioni per la propria scheda madre.
2. Deframmentare con l'ssd??????? Ma assolutamente no! https://www.makeuseof.com/should-you-defrag-an-ssd/
3. Mi sembra più che superfluo.
4. Ti avevo già risposto.

EDIT: @wilecoyote in seguito alla tua osservazione ho modificato così la parte relativa a AHCI:
«nelle impostazioni SATA assicurarsi che sia impostata la modalità AHCI e non IDE. A seconda dei modelli l'opzione potrebbe essere denominata diversamente oppure essere assente (ad esempio perché abilitata di default nei BIOS più recenti). In caso di dubbi fare riferimento alle istruzioni della propria scheda madre».

PS: l'unica parte che avrei voluto più breve è il punto relativo ai backup. Ma per forza di cose alcuni argomenti hanno bisogno di un minimo di approfondimento tecnico. In più sono pochissimi i casi in cui ho sentito di SSD rotti, mai per esperienza diretta. Comunque quando si tratta di sicurezza dei dati - si sa - meglio la paranoia del danno...

Punto 1 sul AHCI così è meglio, mi resta la curiosità di vedere la documentazione relativa ai BIOS dei portatili.

Al punto 2 continuerò a chiedere aiuto in caso di blocchi da mancate deframmentazioni, alla peggio mi tappo le orecchie per non sentire l'insentibile dal sistemista, purtroppo toscano, Arezzo, ed esperto di tirar giù ½ e passa firmamento dei santi.

Sul punto 3 vorrei insistere, dei SSD danneggiati dall'installazione compulsiva di quella e quell'altra distro per provarle l'ho già visti, l'ultimo un SanDisk da 64 GB, che magari era vecchio, del 2017, nondimeno è andato completamente.

Punto 4 aspetto gli sviluppi futuri.

:: Ciao

[xavier77]

Punto 1 sul AHCI così è meglio, mi resta la curiosità di vedere la documentazione relativa ai BIOS dei portatili.

Al punto 2 continuerò a chiedere aiuto in caso di blocchi da mancate deframmentazioni, alla peggio mi tappo le orecchie per non sentire l'insentibile dal sistemista, purtroppo toscano, Arezzo, ed esperto di tirar giù ½ e passa firmamento dei santi.

Sul punto 3 vorrei insistere, dei SSD danneggiati dall'installazione compulsiva di quella e quell'altra distro per provarle l'ho già visti, l'ultimo un SanDisk da 64 GB, che magari era vecchio, del 2017, nondimeno è andato completamente.

Punto 4 aspetto gli sviluppi futuri.

1. Non cerchiamo il pelo nell'uovo, per favore
2. OK chiudiamola qui, anche perché se sento nella stessa frase le parole "deframmentare" e "SSD" mi salgono i succhi gastrici e mi sento male
3. Qualunque scrittura eccessiva comporta usura degli SSD. Nelle due guide è scritto in tutte le salse. Che le scritture siano fatte perché uno cambia distro Linux 4 volte al giorno o perché ci scarica compulsivamente 100 GB ogni ora di film VM18 (esempio a caso), importa poco. Noi riportiamo i casi di scritture su disco più frequenti, per lo più eseguiti inconsapevolmente dall'utente (swap, ibernazione ecc.). Stop.

[emanuc]

Vorrei precisare che anche gli hard disk hanno un ciclo di scrittura.
Tutte le ottimizzazioni sugli SSD che si leggono in giro per il web sono dovuti ai primi SSD che avevano un ciclo di scrittura molto breve, ad oggi gli SSD durano anche più degli hard disk, quindi non ci perderei molto tempo.
Inoltre gli SSD si devono sfruttare per la loro velocità e consigliare di scriverci il meno possibile si ha un effetto opposto, perché la swap su SSD, la cache ecc è molto più veloce se su SSD rispetto a spostarli su hard disk.

[frapox]

Vorrei precisare che anche gli hard disk hanno un ciclo di scrittura.
Tutte le ottimizzazioni sugli SSD che si leggono in giro per il web sono dovuti ai primi SSD che avevano un ciclo di scrittura molto breve, ad oggi gli SSD durano anche più degli hard disk, quindi non ci perderei molto tempo.
Inoltre gli SSD si devono sfruttare per la loro velocità e consigliare di scriverci il meno possibile si ha un effetto opposto, perché la swap su SSD, la cache ecc è molto più veloce se su SSD rispetto a spostarli su hard disk.

Da quello che so io, e quindi magari ignoro qualcosa, gli Hdd meccanici non hanno un limite massimo di scritture, ma sono garantiti per un tot di TB scritti all'anno, e per un tot di cicli attivazione/spegnimento delle testine. Garantiti nel senso che possono anche funzionare oltre, oltre quel numero, ma il produttore non lo garantisce. Gli Ssd (come tutte le Nand flash) invece hanno un numero massimo di scritture prestabilito in fabbrica oltre al quale non puoi andare.

Sulla durata Hdd vs Ssd per me incide molto che uso ne fai, e in che condizioni di temperatura/umidità operano, ad esempio su dei Nas che gestisco, ci sono dei dischi di 10 anni fa ancora funzionanti

Quindi comunque un minimo di precauzione ha senso, ha senso anche cercare di evitare di scrivere centinaia di GB inutilmente, ma senza però perderci il sonno. Però alla fine questo dovrebbe essere demandato all'utente, che è l'unico che può sapere cosa ci fa realmente con la macchina. La wiki dovrebbe illustrare le "best practice", consigli generici comunque validi un po' per tutti.

Al punto 2 continuerò a chiedere aiuto in caso di blocchi da mancate deframmentazioni

In 30 anni di informatica non mi è mai capitato di vedere "blocchi da mancate deframmentazioni", quindi ho ragione di credere che anche questa sia una tua "simpatica" invenzione. E comunque resta il fatto che la deframmentazione genera un numero consistente di scritture, che ne va ad accorciare la vita utile di un SSD in modo sensibile; inutilmente, visto che la frammentazione dei file su un SSD non ha un impatto sulle prestazioni; questo è un dato di fatto, non una teoria.

[emanuc]

Vorrei precisare che anche gli hard disk hanno un ciclo di scrittura.
Tutte le ottimizzazioni sugli SSD che si leggono in giro per il web sono dovuti ai primi SSD che avevano un ciclo di scrittura molto breve, ad oggi gli SSD durano anche più degli hard disk, quindi non ci perderei molto tempo.
Inoltre gli SSD si devono sfruttare per la loro velocità e consigliare di scriverci il meno possibile si ha un effetto opposto, perché la swap su SSD, la cache ecc è molto più veloce se su SSD rispetto a spostarli su hard disk.

Da quello che so io, e quindi magari ignoro qualcosa, gli Hdd meccanici non hanno un limite massimo di scritture, ma sono garantiti per un tot di TB scritti all'anno, e per un tot di cicli attivazione/spegnimento delle testine. Garantiti nel senso che possono anche funzionare oltre, oltre quel numero, ma il produttore non lo garantisce. Gli Ssd (come tutte le Nand flash) invece hanno un numero massimo di scritture prestabilito in fabbrica oltre al quale non puoi andare.

Sulla durata Hdd vs Ssd per me incide molto che uso ne fai, e in che condizioni di temperatura/umidità operano, ad esempio su dei Nas che gestisco, ci sono dei dischi di 10 anni fa ancora funzionanti

Quindi comunque un minimo di precauzione ha senso, ha senso anche cercare di evitare di scrivere centinaia di GB inutilmente, ma senza però perderci il sonno. Però alla fine questo dovrebbe essere demandato all'utente, che è l'unico che può sapere cosa ci fa realmente con la macchina. La wiki dovrebbe illustrare le "best practice", consigli generici comunque validi un po' per tutti.

Al punto 2 continuerò a chiedere aiuto in caso di blocchi da mancate deframmentazioni

In 30 anni di informatica non mi è mai capitato di vedere "blocchi da mancate deframmentazioni", quindi ho ragione di credere che anche questa sia una tua "simpatica" invenzione. E comunque resta il fatto che la deframmentazione genera un numero consistente di scritture, che ne va ad accorciare la vita utile di un SSD in modo sensibile; inutilmente, visto che la frammentazione dei file su un SSD non ha un impatto sulle prestazioni; questo è un dato di fatto, non una teoria.

Un conto è metterlo in un NAS e farci backup, un altro avere un IO intensivo, in questo caso anche l hard disk durerà di meno, tutto dipende dalla qualità del device e da quello che ci fa l'utente, infatti ci sono versioni consumer e pro/aziendali, sia per gli hard disk che per gli SSD.
Ci sono sempre più utenti|utenti aziendali ad avere come storage gli SSD dove hanno bisogno di prestazioni, il problema degli SSD è il costo maggiore rispetto agli HDD, non la sua durata.
Ho preso come esempio un MX crucial da 500gb(consumer), garanzia di scrittura di 180tb, se dovessimo calcolarlo per una durata di 10 anni(ha una garanzia di 5anni) puoi scrivere 1,5tb al mese.
Il rischio è di ritrovarci utenti a non sfruttare gli SSD.
Invece l'operazione più importante che molti ignorano è l'overprovisioning.
In conclusione, rileggendo la guida "ottimizzareSSD" per me va bene così.

[xavier77]

Un conto è metterlo in un NAS e farci backup, un altro avere un IO intensivo, in questo caso anche l hard disk durerà di meno, tutto dipende dalla qualità del device e da quello che ci fa l'utente, infatti ci sono versioni consumer e pro/aziendali, sia per gli hard disk che per gli SSD.
Ci sono sempre più utenti|utenti aziendali ad avere come storage gli SSD dove hanno bisogno di prestazioni, il problema degli SSD è il costo maggiore rispetto agli HDD, non la sua durata.
Ho preso come esempio un MX crucial da 500gb(consumer), garanzia di scrittura di 180tb, se dovessimo calcolarlo per una durata di 10 anni(ha una garanzia di 5anni) puoi scrivere 1,5tb al mese.
Il rischio è di ritrovarci utenti a non sfruttare gli SSD.
Invece l'operazione più importante che molti ignorano è l'overprovisioning.
In conclusione, rileggendo la guida "ottimizzareSSD" per me va bene così.

Ricordo anni fa un collega in un server aziendale mise due SSD in raid e noi gli dicemmo che era pazzo. Però, che io sappia, quel server ha funzionato benissimo per molto tempo (poi non so...).
E comunque sì, gli SSD vanno sfruttati. La mia esperienza personale: nel mio PC principale fino a un paio d'anni fa avevo la configurazione SSD+HDD, dove in quest'ultimo ci mettevo /home, /var e swap. Ebbene con Ubuntu dovevo aspettare 20/30 secondi circa dopo il login su GDM (anche disattivando le estensioni), le macchine virtuali (salvate sempre nella home) erano delle lumache. Risolto tutto quando alla fine ho sostituito l'hard disk con un SSD meno prestante ma più capiente.

Per quanto riguarda l'overprovisioning tutte le guide fino a 6/7 anni fa lo davano di fatto per obbligatorio. Lo potevi fare tu, oppure usando software appositi (es: Magician per samsung). Questo invece un manuale del 2016 per un modello specifico Sandisk (dove consigliano di gestire l'OP con HDAT20 or HDPARM):
https://www.sandisk.com/content/dam/san ... 00-SSD.pdf
Questa la pagina attuale di kingston, dove dicono:
«Terminato l’assemblaggio di un SSD, il produttore può riservare una percentuale aggiuntiva della capacità totale alle funzioni di over-provisioning (OP). Tale operazione viene eseguita durante la fase di programmazione del firmware». Cioè: l'utente non deve fare nulla.
Nella guida, anche in questo caso, si consiglia di consultare quanto dichiarato dal produttore, in base al modello. Che, per inciso, è sempre la cosa migliore da fare, poiché i modelli di SSD non sono tutti uguali (per l'occasione ieri sono andato a "ricicciare" uno dei primissimi modelli di eee PC, che montava Asus Phison, l'SSD più lento che abbia mai visto in vita mia: ovviamente non supporta il TRIM, ha velocità di lettura/scrittura che si avvicina più agli HDD...).

Scusate se mi sono dilungato. Sintetizzando, lo "spirito" delle 2 nuove guide, nelle mie intenzioni dovrebbe essere:

• Stare al passo coi tempi (le istruzioni di anni fa spesso sono inutili o addirittura potenzialmente dannose)
• Prendere i dovuti accorgimenti "di base" (gli SSD non sono come gli HDD)
• Non esagerare con gli accorgimenti!

Mi sembra che rispetto alla versione precedente della guida, contengano molte più procedure, informazioni, consigli, fonti ecc.

Procedo dunque con l'aggiornamento della pagina Hardware/DispositiviPartizioni/Trim
Come sempre, eventuali migliorie possono essere aggiunte anche in seguito.
NB: rimane soltanto parzialmente in sospeso la questione della modifica su Grub in caso di partizioni criptate, che pare non sia più necessaria ma che alcune guide online continuano a riportare. I passaggi sono ancora presenti ma nascosti.
Grazie a tutti per la collaborazione!