Re: Nuova installazione su SSD
Il 17/08/2018 08:40, Luca Costantino ha scritto:
> Il giorno gio 16 ago 2018 alle ore 18:04 Gollum1
> <gollum1.smeagol1@gmail.com <mailto:gollum1.smeagol1@gmail.com>> ha scritto:
>
> personalmente non metterei /home insieme al sistema, nel momento in
> cui dovessi trovarti costretto a reinstallare, perderesti tutto il tuo
> materiale.
>
> L'ultima installazione, sul portatile attuale, risale a fine 2012.
> Diciamo che nonostante SID sia *molto* instabile, si difende bene. Nel
> peggiore dei casi una reinstallazione totale non mi spaventa, ma terro'
> presente il punto.
Io personalmente metto sempre la /home su un altra partizione, meglio
ancora su un disco dedicato (se il portatile supporta le unità SSD M.2
si può usare quest'ultima per i sistemi operativi, e il disco 2.5"
interno per i dati, che è la situazione in cui mi ritrovo io). Questo
permette di ottenere i seguenti vantaggi:
- Poter reinstallare preservando la home, che successivamente si può
rimappare sulla nuova installazione ritrovandosi gli stessi
dati/impostazioni dell'installazione precedente
- Poter condividere la stessa home tra più distribuzioni GNU/Linux (con
le dovute accortezze)
- Poter utilizzare filesystem specifici per i dati nel caso in cui si
abbiano necessità particolari
Alcuni consigli di carattere generale che mi sento di dare sono questi:
- Settare il BIOS/UEFI in modo che il controller SATA utilizzi la
modalità AHCI [0]: questo oltre ad abilitare l'hot swapping che in
questo caso non è rilevante, abilita la modalità NCQ [1] (Native Command
Queuing) che è un estensione delle specifiche SATA che va ad ottimizzare
le letture/scritture dei dati su disco (per maggiori informazioni
consiglio la lettura di questo thread [2])
- Modalità di boot UEFI (se supportata) e conseguente schema di
partizionamento GPT: questo permettere di utilizzare solo partizioni
primarie e di poterne creare quante se ne desiderano = maggiore flessibilità
>
> Magari potresti mettere /boot insieme al resto del sistema
> operativo, visto che non c'é più la necessità di stare entro i primi
> 1024 byte per il loader (già da parecchi anni).
>
> Dovendo cifrare il disco, come sul setup attuale, /boot deve per forza
> essere su una partizione separata e non cifrata. O almeno cosi' era
> qualche anno fa.
Qui non ho mai fatto dei test specifici, ma alcuni punti da tenere
presenti sono:
- /boot/efi non può essere cifrata in quanto è lo stesso BIOS/UEFI che
va a leggere da questa partizione (a meno che non ci siano firmware in
grado di gestire la cifratura, di cui io non sono a conoscenza)
- /boot per comodità non andrebbe cifrata, anche se mi sembra di capire
che è possibile farlo [3]
Ricapitolando potresti avere una schema di partizionamento come segue:
- /dev/sda1 --> /boot/efi --> FAT32
- /dev/sda2 --> boot --> ext2/3/4
- /dev/sda3 --> LUKS + LVM
+ /dev/mapper/root
+ /dev/mapper/home
+ /dev/mapper/swap
+ /dev/mapper/qualcosa
Il disco è così cifrato ad eccezione della sezione di boot; la chiave
per decifrare il volume LUKS ti viene chiesta durante il boot del
sistema operativo.
N.B: è impostante che la partizione di swap sia cifrata, in quanto la
chiave per decifrare il volume LUKS è in RAM e viene scritta su disco
nel momento in cui si va a ibernare (suspend-to-disk) il sistema.
> Consigli per installazione SSD targeted?
Anche su questo punto in giro si trovano tante opinioni, ma in generale
consiglierei di non esagerare con i tweak e le impostazioni.
Partendo dal presupposto che un numero eccessivo di scritture può
accorciare la vita delle unità SSD (questo era più vero anni fa, in
quanto le unità più recenti sono migliorate sotto questo punto di
vista), mi sento di fare le seguenti considerazioni:
- Montare le partizioni con l'opzione noatime: questo previene la
continue scritture dovute all'aggiornamento del campo atime dei file
(last access time)
- Abilitare il TRIM [5] periodico, così che i blocchi non più
utilizzati possano essere ripuliti (tendenzialmente i dischi post 2011
dovrebbero supportare il TRIM); è possibile verificare il supporto con
$ sudo hdparm -I /dev/sdX | grep TRIM
--> * Data Set Management TRIM supported (limit 8 blocks)
Per abilitare il TRIM periodico a livello di sistema operativo si può
fare riferimento alle unità fstrim.service e fstrim.timer che systemd
mette a disposizione (/lib/systemd/system/)
- Evitare di montare le partizioni con l'opzione discard che equivale
al TRIM Continuous, in quanto potrebbe portare ad un degrado delle
prestazioni.
- Evitare che il sistema vada ad utilizzare la partizione di swap
quando non è strettamente necessario; di solito io inserisco la seguente
linea "vm.swappiness=10" (senza virgolette) in /etc/sysctl.conf
Queste sono le impostazioni che io utilizzo e che ho provato; per
maggiori informazioni credo che questa pagina possa essere utile [6]
> Grazie mille
> Luca
Buona giornata
Daniele
[0] https://en.wikipedia.org/wiki/Advanced_Host_Controller_Interface
[1] https://en.wikipedia.org/wiki/Native_Command_Queuing
[2]
https://forums.crucial.com/t5/SSD-Archive-Read-Only/Why-do-i-need-AHCI-with-a-SSD-Drive-Guide-Here-Crucial-AHCI-vs/td-p/57078
[3]
https://superuser.com/questions/649091/uefi-and-full-disk-encryption-with-lvm-on-luks/1139576
[5] https://en.wikipedia.org/wiki/Trim_(computing)
[6] https://sites.google.com/site/easylinuxtipsproject/ssd
Reply to: