[Nuova guida] SSD e TRIM su Ubuntu

[frapox]

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.

Per scrupolo e per curiosità ho fatto una install pulita di Focal con partizione root criptata, usando il suo installer con l'opzione "altro" (visto che non c'è nelle opzioni avanzate dell'installer la criptazione della root).

A fine installazione, al primo reboot, ho recuperato le seguenti info:

Codice: Seleziona tutto

$ cat /sys/block/sda/queue/rotational 
0

$ cat /etc/crypttab
sda3_crypt UUID=d22afacd-ed0a-491a-83c5-cf3b77c7cb98 none luks,discard

$ cat /etc/default/grub | grep LINUX_DEFAULT
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

$ cat /proc/cmdline 
BOOT_IMAGE=/vmlinuz-5.4.0-26-generic root=UUID=f48b740b-939a-402c-8a1b-79c1dcebf8fe ro quiet splash vt.handoff=7

$ lsblk /dev/sda
NAME           MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda              8:0    0   20G  0 disk  
├─sda1           8:1    0   60M  0 part  /boot/efi
├─sda2           8:2    0  954M  0 part  /boot
└─sda3           8:3    0   19G  0 part  
  └─sda3_crypt 253:0    0   19G  0 crypt /


$ cat /etc/fstab | grep sda3
/dev/mapper/sda3_crypt /               ext4    errors=remount-ro 0       1

# cryptsetup status sda3_crypt 
/dev/mapper/sda3_crypt is active and is in use.
  type:    LUKS2
  cipher:  aes-xts-plain64
  keysize: 512 bits
  key location: keyring
  device:  /dev/sda3
  sector size:  512
  offset:  32768 sectors
  size:    39829504 sectors
  mode:    read/write
  flags:   discards

Quindi per me non ci sono dubbi che almeno dalla 20.04 non c'è più bisogno dei parametri del kernel per attivare il trim su SSD ma solo l'opzione discard in crypttab, e questa viene inserita automaticamente dall'installer.

Se utile potrei fare una prova anche con la 18.04 appena riesco.

Grazie a tutti per la collaborazione!

Grazie a te della perseveranza.

[xavier77]

Per scrupolo e per curiosità ho fatto una install pulita di Focal con partizione root criptata, usando il suo installer con l'opzione "altro" (visto che non c'è nelle opzioni avanzate dell'installer la criptazione della root).

A fine installazione, al primo reboot, ho recuperato le seguenti info:

Codice: Seleziona tutto

$ cat /sys/block/sda/queue/rotational 
0

$ cat /etc/crypttab
sda3_crypt UUID=d22afacd-ed0a-491a-83c5-cf3b77c7cb98 none luks,discard

$ cat /etc/default/grub | grep LINUX_DEFAULT
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

$ cat /proc/cmdline 
BOOT_IMAGE=/vmlinuz-5.4.0-26-generic root=UUID=f48b740b-939a-402c-8a1b-79c1dcebf8fe ro quiet splash vt.handoff=7

$ lsblk /dev/sda
NAME           MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda              8:0    0   20G  0 disk  
├─sda1           8:1    0   60M  0 part  /boot/efi
├─sda2           8:2    0  954M  0 part  /boot
└─sda3           8:3    0   19G  0 part  
  └─sda3_crypt 253:0    0   19G  0 crypt /


$ cat /etc/fstab | grep sda3
/dev/mapper/sda3_crypt /               ext4    errors=remount-ro 0       1

# cryptsetup status sda3_crypt 
/dev/mapper/sda3_crypt is active and is in use.
  type:    LUKS2
  cipher:  aes-xts-plain64
  keysize: 512 bits
  key location: keyring
  device:  /dev/sda3
  sector size:  512
  offset:  32768 sectors
  size:    39829504 sectors
  mode:    read/write
  flags:   discards

Quindi per me non ci sono dubbi che almeno dalla 20.04 non c'è più bisogno dei parametri del kernel per attivare il trim su SSD ma solo l'opzione discard in crypttab, e questa viene inserita automaticamente dall'installer.

Se utile potrei fare una prova anche con la 18.04 appena riesco.

Ti ringrazio della segnalazione. Non occorre provare con le 18.04.
Ho modificato la guida in modo tale che se l'opzione c'è già bene così, se invece manca si aggiunge e tanti saluti

[ivantu]

Vedete... che io avevo ragione, riguardo discard?

Quanto vi è costato provare a fare una nuova installazione di Ubuntu e verificare?

[xavier77]

Vedete... che io avevo ragione, riguardo discard?

Quanto vi è costato provare a fare una nuova installazione di Ubuntu e verificare?

Mi sembra che tu non abbia capito, qui non si parlava di /etc/fstab.
Per favore rileggi bene tutta la discussione (o almeno dalla pagina 2 in poi).


EDIT:
@ivantu
siccome il forum non è una chat, ti rispondo qui anziché continuare sotto.
Un paio di interventi sopra si parlava dell'opzione discard in /etc/crypttab, non in /etc/fstab come invece hai inteso tu (prova ne è anche l'intervento sotto).
Prima di intervenire sarebbe opportuno come minimo che tu sappia di cosa si sta parlando.
Infine ti invito a mantenere toni più pacati e non provocatori: specialmente in questa sezione, i flame non sono per niente belli.
Regolati tu.

[ivantu]

Vedete... che io avevo ragione, riguardo discard?

Quanto vi è costato provare a fare una nuova installazione di Ubuntu e verificare?

Mi sembra che tu non abbia capito, qui non si parlava di /etc/fstab.
Per favore rileggi bene tutta la discussione (o almeno dalla pagina 2 in poi).

Tu non hai capito bene il mio messaggio. Io ho parlato di /etc/fstab.. di entrambi i file
Da quando è diventato inconcepibile discutere di /etc/fstab nelle discussioni?

Fai ora anche tu parte di quelli che insabbiano le discussioni?
@#xavier77 vi conviene prendervi della pausa, il caldo sta causando non pochi problemi nelle discussioni. Credimi... ti consiglio obbligatoriamente.

[frapox]

Vedete... che io avevo ragione, riguardo discard?

Quanto vi è costato provare a fare una nuova installazione di Ubuntu e verificare?

Mi sembra che tu non abbia capito, qui non si parlava di /etc/fstab.
Per favore rileggi bene tutta la discussione (o almeno dalla pagina 2 in poi).

Tu non hai capito bene il mio messaggio. Io ho parlato di /etc/fstab.. di entrambi i file
Da quando è diventato inconcepibile discutere di /etc/fstab nelle discussioni?

Infatti ne abbiamo già discusso e abbiamo concluso che mettere "discard" come parametro di mount (sotto fstab) non serve ed è anzi controproducente. Mentre sotto crypttab lo stesso parametro è invece utile, vedi sopra.

crypttab e fstab fanno due cose diverse, nel caso non lo sapessi, dare un'occhiata al manuale di entrambi può aiutare.

Fai ora anche tu parte di quelli che insabbiano le discussioni?
@#xavier77 vi conviene prendervi della pausa, il caldo sta causando non pochi problemi nelle discussioni. Credimi... ti consiglio obbligatoriamente.

Visto che l'unico a non aver capito di cosa si stava parlando sembra sia tu, anziché dare delle risposte del genere, vai a rileggere la discussione, perchè è tutto piuttosto chiaro, quindi è inutile ripetersi.

[emanuc]

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

Potremmo riconsiderare l'opzione discard async su Btrfs come "consigliata", perché in base a quel che ho letto sulal ML non ci sono motivi reali per non farlo e sembra migliore rispetto a un trim settimanale:

Hey all,

I was talking with Chris Mason today at a Fedora Hatch event about
async discards (as we were thinking about doing this in Fedora some
time ago[1]), and he seemed to consider it reasonable to make it so
Btrfs uses async discards by default when being formatted on SSDs.

He and I couldn't think of a reason why not to, other than the
potential lack of "discard=none" option to turn off discards if the
user wanted it to. Do we already have this option? Are there any other
reasons not to do this? Or is this something we should have changed in
Btrfs so everyone gets async discards by default going forward?

Thanks in advance and best regards,
Neal

Su Fedora stanno riconsiderando di abilitarlo di default.
In ogni caso per fare delle modifiche alla WIKI aspettiamo come si evolve la situazione e le varie discussioni.
https://pagure.io/fedora-btrfs/project/issue/6

Già c'è una patch che abilita discard async in automatico su Btrfs, sembra dal kernel 5.20.
https://patchwork.kernel.org/project/li ... 9@suse.cz/