[Nuova guida] SSD e TRIM su Ubuntu

[wilecoyote]

) Salve, i 2 comandi di verifica funzionano anche in Jammy 22.04 LTS e Bionic 18.04.6 LTS.

Supposto d'esserci un problema col Trim il mese scorso post avanzamento di versione, in un SSD Sandisk da 240 GB, ma non c'entrava nulla coi problemi, ppa non disabilitato.

Sempre su systemd, anch'esso può attivarlo/disattivarlo/fermarlo/riavviarlo.

Nella wiki si cita di verificare d'aver un kernel successivo al 2.6.33, vorrei vedere chi ancora l'usa.

Non mi pare di ricordare che hdparm sia preinstallato, ma bensì vada installato di proposito, cosa logica visti i danni potenziali che può fare se usato in modo malaccorto.

Chiederei a @emanuc se può aggiungere qualche nota pell'uso col Btrfs, oggidì è più diffuso di quanto si pensi.

:: Ciao

Link alla wiki Hardware/DispositiviPartizioni/Trim

[ivantu]

Lascio ai più esperti.
Se c'è qualche modifica fate pure.

[xavier77]

Intanto ho aggiunto un paragrafo nascosto per l'uso di systemd.
Nel frattempo mi sono anche documentato (wiki arch, altri articoli ecc.).
Sarò molto sintetico.
Da quello che ho capito, se si ha un SSD recente e un sistema recente (ossia degli ultimi 10 anni) non occorre fare nulla (il TRIM settimanale con sysytemd andrebbe più che bene).
Diverso per i casi particolari (es: SSD vecchissimi, di marche "strane", esigenze particolari del sistema, o di eventuali software, o dell'utente ecc.).
Ecco: io espliciterei questo aspetto.
In più (ancora non ho avuto modo) verificherei cosa comporta avere il servizio abilitato sia tramite list-timers di systemd che su cron, se sia preferibile l'uno o l'altro, se bisogna poi disabilitare qualcosa ecc.

L'osservazione su hdparm di wilecoyote mi sembra sensata.

Per il momento lasciamo così com'è la guida (che comunque è verificata). Mettiamo però in programma ulteriori modifiche, dopo aver consultato qualche manuale e sentito il pare di altri utenti (compreso ivantu, che avrà anche fatto dei test, immagino...).

[frapox]

Da quello che ho capito, se si ha un SSD recente e un sistema recente (ossia degli ultimi 10 anni) non occorre fare nulla (il TRIM settimanale con sysytemd andrebbe più che bene).

Esatto.

Diverso per i casi particolari (es: SSD vecchissimi, di marche "strane", esigenze particolari del sistema, o di eventuali software, o dell'utente ecc.).

Di hard disk che hanno problemi col trim ce ne sono pochi, alcuni modelli neanche tanto vecchi danno problemi con il "queued trim", ma il kernel li blacklista già di default (addirittura disattivando il NCQ):
https://www.phoronix.com/scan.php?page= ... ore-Quirks

In più (ancora non ho avuto modo) verificherei cosa comporta avere il servizio abilitato sia tramite list-timers di systemd che su cron, se sia preferibile l'uno o l'altro, se bisogna poi disabilitare qualcosa ecc.

È inutile avere sia il cronjob che il timer di systemd attivi, sono uno alternativo all'altro. Tuttavia anche avendoli attivi entrambi non dovrebbe capitare nulla di grave, il peggio che può succedere è che ti partano due fstrim a settimana anziché uno.

Tutte le versioni supportate attualmente (dalla 18.04 in avanti) usano il timer di systemd quindi credo che le istruzioni sul cronjob ormai siano da ritenersi obsolete.

[emanuc]

Di default non ci sono differenze tra filesystem, mi riferisco al post install su Ubuntu e derivate che abilita il trim in automatico tramite il timer di systemd.

Ad eccezione se facciamo riferimento alle opzioni di mount, ma in questo caso si dovrebbe disabilitare il timer.

Abilitazione del TRIM attraverso fstab

Aprire con un editor di testo ed i privilegi di amministrazione il file /etc/fstab ed aggiungere le opzioni «discard» (ed eventualmente anche «noatime») come nell'esempio successivo:

Questa parte è utile? Ormai Ubuntu in tutte le versioni supportate abilita di default il trim settimanale.
Se si va nella guida delle opzioni di mount rispetto al timer settimanale, si dovrebbe guidare gli utenti dei FS Btrfs e XFS che supportano l'opzione di mount "discard async"[1], anche se dubito che gli utenti desktop ne abbiano beneficio visto che si parla di carichi di lavoro non desktop, ma sicuramente la WIKI non è indirizzata solo agli utenti desktop?
Se guidiamo l'utente all'opzione di mount, dovremmo guidarlo anche a disabilitare il timer.
[1] https://www.phoronix.com/scan.php?page= ... nc-Discard

Non so se ad oggi è ancora valido, ma non molto tempo fa l'opzione di mount "discard" era sconsigliata rispetto a un TRIM settimanale a causa del comportamento di alcuni firmware che causavano problemi.
Per il resto non mi sembra che ci sia qualcosa di specifico per FS.

Una miglioria su questo comando, invece di usare "grep":

Codice: Seleziona tutto

cat /etc/mtab | grep ext4

a

Codice: Seleziona tutto

mount -t filesystem

esempio:

Codice: Seleziona tutto

mount -t ext4

[frapox]

Di default non ci sono differenze tra filesystem, mi riferisco al post install su Ubuntu e derivate che abilita il trim in automatico tramite il timer di systemd.

Quoto.

Non so se ad oggi è ancora valido, ma non molto tempo fa l'opzione di mount "discard" era sconsigliata rispetto a un TRIM settimanale a causa del comportamento di alcuni firmware che causavano problemi.
Per il resto non mi sembra che ci sia qualcosa di specifico per FS.

L'opzione di mount discard andrebbe proprio sconsigliata perché porta a un decremento sensibile delle prestazioni del SSD a fronte di vantaggi sostanzialmente nulli. Con gli SSD moderni un Trim a settimana è più che sufficiente.

[emanuc]

PS:

Poiché sono in pochi ad utilizzare il filesystem BTRFS, la guida verterà sull'abilitazione del TRIM sul filesystem EXT4.

Non so quando è stato scritto, ma ad oggi non è veritiero, molte distro lo hanno di default: openSUSE, Fedora, Garuda, popOS sta pianificando per averlo di default, anche molti utenti di Ubuntu e derivate lo usano.

[xavier77]

Allora, alla luce dei vostri consigli e delle informazioni più recenti reperite in rete, nonché alcuni test, ho buttato giù due guide.
Una su consigli generali sugli accorgimenti da adottare con gli SSD.
Un'altra specifica per il TRIM (se no veniva una guida troppo lunga).
Sono ancora in una fase molto grossolana, ma hanno già chiara la struttura che vorrei impostare, gli argomenti, le procedure ecc.

Intanto dateci un'occhiata, poi ditemi se ci sono cose da correggere, inserire, segnalare ecc.
andreas-xavier/OttimizzareSSD
andreas-xavier/ProvaTrim

[wilecoyote]

) Salve, forse ho scoperto l'acqua calda, però verificando dal terminale il Trim, ho notato un comportamento apparentemente assai bizzarro nel mio Kubuntu Bionic 18.04.6 LTS, installato s'un HDD.

Ogni tanto mi capita di connettere un SSD, sempre lo stesso, tramite case USB, che viene usato in un data logger per registrare i dati sui consumi energetici di vari clienti, dati che scarico ed uso per aggiornare delle tabelle tramite Calligra Sheets.

Orbene, a quanto pare questo SSD viene riconosciuto e considerato un ospite abituale dal sistema, e come tale viene oggetto di periodiche attivazioni del FSTrim.

Domanda, dato che non è presente nel file /etc/fstab, come piffero viene tenuta memoria nel sistema di questo SSD e dei relativi tempi d'uso ?

:: Ciao

P.S. do un'occhiata alle nuove wiki, intanto credo che quella sui SSD dovrà essere dotata di propria discussione.

[xavier77]

) Salve, forse ho scoperto l'acqua calda, però verificando dal terminale il Trim, ho notato un comportamento apparentemente assai bizzarro nel mio Kubuntu Bionic 18.04.6 LTS, installato s'un HDD.

Ogni tanto mi capita di connettere un SSD, sempre lo stesso, tramite case USB, che viene usato in un data logger per registrare i dati sui consumi energetici di vari clienti, dati che scarico ed uso per aggiornare delle tabelle tramite Calligra Sheets.

Orbene, a quanto pare questo SSD viene riconosciuto e considerato un ospite abituale dal sistema, e come tale viene oggetto di periodiche attivazioni del FSTrim.

Domanda, dato che non è presente nel file /etc/fstab, come piffero viene tenuta memoria nel sistema di questo SSD e dei relativi tempi d'uso ?

Piccolo OT, ma ti rispondo
Quando viene eseguito dal sistema il comando trim, questo agisce su tutte le partizioni montate e che lo supportano.
In realtà poi bisognerebbe vedere il modello e in che modalità esegue il trim, nonché se e come è impostato il trim nel tuo sistema ecc.....
Va be', tornando alle guide...

P.S. do un'occhiata alle nuove wiki, intanto credo che quella sui SSD dovrà essere dotata di propria discussione.

In realtà non ne vedo il bisogno, almeno per il momento. Non sempre conviene aprire una discussione per ogni pagina wiki.
Al contrario, come in casi come questo, se gli argomenti sono simili se ne può mantenere benissimo una sola.

[emanuc]

Ho letto le guide, ho alcune considerazione da fare:

Operazioni sulla memoria di swap

A seconda dei casi può essere utile:

Disattivare la swap (se si hanno a disposizione almeno 4/8 GB di RAM).
Impostare la swap su partizione o file dedicati allocati in un disco rigido interno, se possibile.
Aumentare il valore di swappiness.

Per tutte le procedure consultare questa guida.

Ad oggi attivare la swap non crea nessun problema nell'usura sugli SSD recenti, inoltre con 4/8GB di ram la swap la consiglierei, anzi la consiglierei sempre.

Preload e Prelink (facoltativo)

Questa procedura potrebbe comportare un maggiore tempo di avvio del sistema operativo.

Ha più dei contro che dei pro nell'ottimizzazione degli SSD, queste configurazioni erano utili quando si usano gli HDD a causa della lentezza nell'apertura dei software, ma gli SSD non soffrono di questo problema (tranne chi usa le APP snap...) quindi non la metterei tra le ottimizzazioni SSD.


Tra le ottimizzazioni aggiungere le opzioni di mount:
Per ext4/btrfs e altri FS:

Codice: Seleziona tutto

noatime

Specifico per Btrfs:
da specificare che bisogna disattivare il trim settimanale e che bisogna attivarlo per carichi di lavoro con molto IO, non indirizzato ai comuni utenti desktop (sopra ho messo il link su questa ottimizzazione)

By doing the SSD DISCARD work asynchronously, Facebook found on their Btrfs servers that the discarding is done more efficiently and read latencies were reduced.

Codice: Seleziona tutto

discard=async

Abilitare la compressione, aiuta a velocizzare l'IO e la durata degli SSD (scrive e legge meno).

Codice: Seleziona tutto

compress=zstd:1

Per CPU meno potenti, non recenti:

Codice: Seleziona tutto

compress=lzo

L'opzione di compress zstd da validare solo per Ubuntu 20.04 o superiore.

[xavier77]

Ad oggi attivare la swap non crea nessun problema nell'usura sugli SSD recenti, inoltre con 4/8GB di ram la swap la consiglierei, anzi la consiglierei sempre.

D'accordo con te, ho sostituito il paragrafo con un link alla guida apposita per la swap, che diceva le stesse ed identiche cose.

Preload e Prelink:
Ha più dei contro che dei pro nell'ottimizzazione degli SSD, queste configurazioni erano utili quando si usano gli HDD a causa della lentezza nell'apertura dei software, ma gli SSD non soffrono di questo problema (tranne chi usa le APP snap...) quindi non la metterei tra le ottimizzazioni SSD.

Mi sono documentato, dovrebbe proprio essere così. Eliminato il paragrafo.

Tra le ottimizzazioni aggiungere le opzioni di mount:
Per ext4/btrfs e altri FS:

Codice: Seleziona tutto

noatime

Specifico per Btrfs:
da specificare che bisogna disattivare il trim settimanale e che bisogna attivarlo per carichi di lavoro con molto IO, non indirizzato ai comuni utenti desktop (sopra ho messo il link su questa ottimizzazione)

By doing the SSD DISCARD work asynchronously, Facebook found on their Btrfs servers that the discarding is done more efficiently and read latencies were reduced.

Codice: Seleziona tutto

discard=async

Abilitare la compressione, aiuta a velocizzare l'IO e la durata degli SSD (scrive e legge meno).

Codice: Seleziona tutto

compress=zstd:1

Per CPU meno potenti, non recenti:

Codice: Seleziona tutto

compress=lzo

L'opzione di compress zstd da validare solo per Ubuntu 20.04 o superiore.

Inserito paragrafo sulle opzioni di mount su fstab.
Oltre che noatime ho messo anche relatime (tradizionalmente "una via di mezzo").
Per quanto riguarda le opzioni per brtfs purtroppo non ne capisco molto (mai utilizzato quel FS).
Ho visto inoltre ci sono delle informazioni specifiche per SSD nelle guide dedicate (seppur "sparpagliate").
Vedo due strade:

• Completare il paragrafo nella pagina di prova, se vuoi darmi una mano ...
• Inserirle nella guida di btrfs e linkarle

Intanto grazie!

[emanuc]

Per l'ozione di mount "discard=async"

Btrfs servers that the discarding is done more efficiently and read latencies were reduced

Quindi è principalmente orientato a chi vuole liberare blocchi in continuazione, rispetto all'opzione di mount "discard" si ha un effcienza maggiore nell'eliminazione dei blocchi e minor latenza in lettura.

Oltre che noatime ho messo anche relatime (tradizionalmente "una via di mezzo").

"relatime" è l'opzione di mount predefinita su tutti i filesystem, specificare che è il default? Lasciarla solo per capire le differenze tra "noatime" e "relatime"?

Per quanto riguarda le opzioni per brtfs purtroppo non ne capisco molto (mai utilizzato quel FS).
Ho visto inoltre ci sono delle informazioni specifiche per SSD nelle guide dedicate (seppur "sparpagliate").

Btrfs rileva in automatico un SSD ed abilita l'opzione di mount "ssd", nel 99% dei casi non c'è bisogno di abilitarlo su "fstab".

Questo è ciò che dice la documentazione su questa opzione di mount (ovviamente l'ho incollato tradotto da Google):

ssd, ssd_spread, nossd, nossd_spread
(predefinito: SSD rilevato automaticamente)

Opzioni per controllare gli schemi di allocazione SSD. Per impostazione predefinita, BTRFS abiliterà o disabiliterà le ottimizzazioni SSD a seconda dello stato di un dispositivo rispetto al tipo rotazionale o non rotazionale. Ciò è determinato dal contenuto di /sys/block/DEV/queue/rotational ). Se è 0, l' opzione ssd è attivata. L'opzione nossd disabiliterà il rilevamento automatico.

Le ottimizzazioni sfruttano l'assenza della penalità di ricerca inerente ai dispositivi di rotazione. I blocchi possono essere in genere scritti più velocemente e non vengono scaricati su thread separati.

Nota

Dalla versione 4.14, le ottimizzazioni del layout dei blocchi sono state eliminate. Questo aiutava con le prime generazioni di dispositivi SSD. Il loro FTL (strato di traduzione del flash) non era efficace e l'ottimizzazione avrebbe dovuto migliorare l'usura allineando meglio i blocchi. Questo non è più vero con i moderni dispositivi SSD e l'ottimizzazione non ha avuto alcun reale vantaggio. Inoltre ha causato una maggiore frammentazione. L'ottimizzazione del layout è stata mantenuta intatta per l'opzione ssd_spread .

L' opzione di montaggio ssd_spread tenta di allocare blocchi più grandi e allineati di spazio inutilizzato e potrebbe funzionare meglio su SSD di fascia bassa. ssd_spread implica ssd , abilitando anche tutte le altre euristiche SSD. L'opzione nossd disabiliterà tutte le opzioni SSD mentre nossd_spread disabilita solo ssd_spread .

Non metterei tutte queste spiegazioni, magari solo il questa parte:
ssd Abilita alcune ottimizzazioni sugli SSD, viene abilitato in automatico al rilevamento di un SSD.

Per l'opzione compress, si potrebbe aggiungere il link alla guida: https://wiki.ubuntu-it.org/Hardware/Dis ... mpressione

[xavier77]

Per l'ozione di mount "discard=async"

Btrfs servers that the discarding is done more efficiently and read latencies were reduced

Quindi è principalmente orientato a chi vuole liberare blocchi in continuazione, rispetto all'opzione di mount "discard" si ha un effcienza maggiore nell'eliminazione dei blocchi e minor latenza in lettura.

Oltre che noatime ho messo anche relatime (tradizionalmente "una via di mezzo").

"relatime" è l'opzione di mount predefinita su tutti i filesystem, specificare che è il default? Lasciarla solo per capire le differenze tra "noatime" e "relatime"?

Per quanto riguarda le opzioni per brtfs purtroppo non ne capisco molto (mai utilizzato quel FS).
Ho visto inoltre ci sono delle informazioni specifiche per SSD nelle guide dedicate (seppur "sparpagliate").

Btrfs rileva in automatico un SSD ed abilita l'opzione di mount "ssd", nel 99% dei casi non c'è bisogno di abilitarlo su "fstab".

Questo è ciò che dice la documentazione su questa opzione di mount (ovviamente l'ho incollato tradotto da Google):

ssd, ssd_spread, nossd, nossd_spread
(predefinito: SSD rilevato automaticamente)

Opzioni per controllare gli schemi di allocazione SSD. Per impostazione predefinita, BTRFS abiliterà o disabiliterà le ottimizzazioni SSD a seconda dello stato di un dispositivo rispetto al tipo rotazionale o non rotazionale. Ciò è determinato dal contenuto di /sys/block/DEV/queue/rotational ). Se è 0, l' opzione ssd è attivata. L'opzione nossd disabiliterà il rilevamento automatico.

Le ottimizzazioni sfruttano l'assenza della penalità di ricerca inerente ai dispositivi di rotazione. I blocchi possono essere in genere scritti più velocemente e non vengono scaricati su thread separati.

Nota

Dalla versione 4.14, le ottimizzazioni del layout dei blocchi sono state eliminate. Questo aiutava con le prime generazioni di dispositivi SSD. Il loro FTL (strato di traduzione del flash) non era efficace e l'ottimizzazione avrebbe dovuto migliorare l'usura allineando meglio i blocchi. Questo non è più vero con i moderni dispositivi SSD e l'ottimizzazione non ha avuto alcun reale vantaggio. Inoltre ha causato una maggiore frammentazione. L'ottimizzazione del layout è stata mantenuta intatta per l'opzione ssd_spread .

L' opzione di montaggio ssd_spread tenta di allocare blocchi più grandi e allineati di spazio inutilizzato e potrebbe funzionare meglio su SSD di fascia bassa. ssd_spread implica ssd , abilitando anche tutte le altre euristiche SSD. L'opzione nossd disabiliterà tutte le opzioni SSD mentre nossd_spread disabilita solo ssd_spread .

Non metterei tutte queste spiegazioni, magari solo il questa parte:
ssd Abilita alcune ottimizzazioni sugli SSD, viene abilitato in automatico al rilevamento di un SSD.

Per l'opzione compress, si potrebbe aggiungere il link alla guida: https://wiki.ubuntu-it.org/Hardware/Dis ... mpressione

Grazie!
Pian piano le pagine di prova stanno prendendo forma (e senso!).
Qualcuno sa se ha senso attualmente questo paragrafo?
andreas-xavier/ProvaTrim#Partizioni_criptate

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

[frapox]

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.

SSD TRIM

A Btrfs filesystem is able to free unused blocks from an SSD drive supporting the TRIM command. Starting with kernel version 5.6 there is asynchronous discard support, enabled with mount option discard=async. Freed extents are not discarded immediately, but grouped together and trimmed later by a separate worker thread, improving commit latency.

https://wiki.archlinux.org/title/Btrfs#SSD_TRIM

Qualcuno sa se ha senso attualmente questo paragrafo?
andreas-xavier/ProvaTrim#Partizioni_criptate

Nelle installazioni di Debian fatte sulla mia macchina, il "discard" l'ho sempre messo nelle opzioni di crypttab: in pratica quando systemd legge crypttab, apre il container, dice al kernel di passare i comandi di Trim al disco. Non ho mai dovuto specificare "allow-discards root_trim=yes" nei parametri di avvio, che mi ricordi. Ma dovrei fare una prova per verificare se questo avvenga anche su ubuntu. Stay tuned.

edit: @xavier77 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).

Codice: Seleziona tutto

# cryptsetup status luks-efdbf8d6-07a4-4e5e-aeb6-045f46a05b64 
/dev/mapper/luks-efdbf8d6-07a4-4e5e-aeb6-045f46a05b64 is active and is in use.
  type:    LUKS1
  cipher:  aes-xts-plain64
  keysize: 512 bits
  key location: dm-crypt
  device:  /dev/sda2
  sector size:  512
  offset:  4096 sectors
  size:    976635904 sectors
  mode:    read/write
  flags:   discards  <----

Codice: Seleziona tutto

# cat /proc/cmdline
BOOT_IMAGE=/ubuntu/boot/vmlinuz-5.15.0-40-generic root=UUID=6006f05a-6bbd-478c-a838-e7e7965dcb9f ro rootflags=subvol=ubuntu

[xavier77]

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

[frapox]

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

Ok, no problem. Aggiungo solo che dovrebbe essere così anche sulla 20.04 che provai tempo addietro. Insomma non ho mai dovuto aggiungere quei parametri di boot, ecco. Forse servivano sui rilasci precedenti.

[xavier77]

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

Ok, no problem. Aggiungo solo che dovrebbe essere così anche sulla 20.04 che provai tempo addietro. Insomma non ho mai dovuto aggiungere quei parametri di boot, ecco. Forse servivano sui rilasci precedenti.

A scopo di test, potresti postare il comando

Codice: Seleziona tutto

lsblk -D

?
ovviamente puoi postare soltanto la riga relativa alla partizione criptata
Grazie!
Ho implementato la pagina di prova sul TRIM. Ho nascosto la parte relativa alla modifica di grub (però alcune guide recenti la riportano ancora).

Sciolti questi ultimi nodi mi pare che le due pagine di prova siano complete. Attendo altre eventuali segnalazioni.

[frapox]

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

Ok, no problem. Aggiungo solo che dovrebbe essere così anche sulla 20.04 che provai tempo addietro. Insomma non ho mai dovuto aggiungere quei parametri di boot, ecco. Forse servivano sui rilasci precedenti.

A scopo di test, potresti postare il comando

Codice: Seleziona tutto

lsblk -D

?
ovviamente puoi postare soltanto la riga relativa alla partizione criptata

Codice: Seleziona tutto

# lsblk -D
NAME                                          DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda                                                  0        4K       2G         0
├─sda1                                               0        4K       2G         0
└─sda2                                               0        4K       2G         0
  └─luks-efdbf8d6-07a4-4e5e-aeb6-045f46a05b64        0        4K       2G         0

sda2 è la partizione criptata, luks-efdbf8d6-07a4-4e5e-aeb6-045f46a05b64 è il volume Btrfs in cui ho root, home e altri subvolume.