Re: Nuova installazione su SSD
On Fri, Aug 17, 2018 at 11:53:55AM +0200, Daniele Piccoli wrote:
> 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
Piazzare /home in una partizione dedicata e' una ottima idea, tuttavia
pur comprendendo i timori che suscitano i dischi SSD, non vedo la
necessita' di mettere /home o altre directory su dischi esterni,
a maggior ragione su dischi non SSD.
> 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]
Quindi ricordavo bene? GRUB2 supporta le partizioni criptate?
> 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.
Qui, SOLO se NON usi il suspend-to-disk, puoi utilizzare una chiave random,
che cripta la partizione di swap[1], con il vantaggio di non dovere
inserire ogni volta una password.
> > 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.
Concordo
> 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)
Non concordo. In virtù di quanto riportato sopra utilizzerei
relatima. man mount per approfondimenti.
> - 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/)
Interessante, ero rimasto a fstrim lanciato da cron
> - Evitare di montare le partizioni con l'opzione discard che equivale
> al TRIM Continuous, in quanto potrebbe portare ad un degrado delle
> prestazioni.
Assolutamente
> - 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
Io non aggiusterei lo swappiness in funzione del disco, ma in funzione
del sistema. Generalmente lascerei invariata questa voce.
> Queste sono le impostazioni che io utilizzo e che ho provato; per
> maggiori informazioni credo che questa pagina possa essere utile [6]
Aggiungere due elementi da studiare:
Approfondirei l'argomento I/O Scheduler, negli anni si sono susseguite
diverse analisi, da una parte leggi una cosa e da un altra leggi l'opposto.
Io non lo uso, come consigliavano agli albori
[noop] deadline cfq
Approfondirei l'argomento file system, con il tempo ne sono cicciati
fuori parecchi, specifici per SSD. Nulla di definitivo e forse
nulla che abbia mai superato lo staging, ma sicuramente una lettura interessante.
A livello fisico oramai i dischi SSD sono maturi, anche se non credo
siano mai stati "immaturi", si tratta solo di renderli piu' durevoli.
Non si leggono in rete di episodi diffusi di malfunzionamenti. Anche
il discorso del "limitare l'I/O" alla fine non si trovano in rete
tracce di disastri accaduti a chi non ha preso queste precauzioni.
Personalmente lancio fstrim a mano ogni volta che me ne ricordo,
quando magari mi serve un po di spazio.
> > 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
[1] https://nwrickert2.wordpress.com/2012/04/21/encypted-swap/
--
Felipe Salvador
Reply to: