Re: Nuova installazione su SSD
Il 17/08/2018 14:29, Felipe Salvador ha scritto:
> 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.
Non ho parlato di dischi esterni ma di un disco interno aggiuntivo;
quando ho la possibilità di avere più dischi sulla macchina preferisco
sempre separare S.O. dai dati.
>> 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?
Non ho mai provato, ma sembra di si [0]
>> 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.
Interessante, grazie :)
>>> 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.
*relatime*
Update inode access times relative to modify or change time. Access
time is only updated if the previous access time was earlier than the
current modify or change time. (Similar to noatime,
but it doesn't break mutt or other applications that need to know if a
file has been read since the last time it was modified.)
Since Linux 2.6.30, the kernel defaults to the behavior provided by
this option (unless noatime was specified), and the strictatime option
is required to obtain traditional semantics. In
addition, since Linux 2.6.30, the file's last access time is always
updated if it is more than 1 day old.
È quindi sufficiente non impostare la modalità noatime nelle opzioni di
mount per avere come comportamento predefinito relatime?
Altri spunti dalla pagina wiki di Debian [1]:
Add the "noatime" (or "relatime") mount option in /etc/fstab, to disable
(or significantly reduce) disk writes whenever a file is read. Please
note that since Linux kernel 2.6.30, "relatime" is the default.
>> - 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
$ sudo cp /lib/systemd/system/fstrim.{service,timer} /etc/systemd/system
$ sudo systemctl enable fstrim.timer
Attenzione che questo abiliterà il TRIM settimanale su _tutti_ i
filesystem montati. Mi sembra di aver visto da qualche parte che
utilizzare TRIM su partizione cifrate senza le dovute accortezze può
portare a problemi di sicurezza; visto che ho da poco spostato la mia
home su ssd approfondirò la questione prossimamente.
Nel caso in cui si voglia limitare l'esecuzione del TRIM su determinati
mountpoint è necessario modificare /etc/systemd/system/fstrim.service
>> - 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.
Credo sia doveroso fare una precisazione: dipende da quanta RAM è
installata nel sistema. Personalmente tendo a ridurre questo valore
sulle mie macchine, in quanto ho almeno 16gb a disposizione e sui
virtualizzatori dove ne ho anche di più :)
Quindi è necessario valutare, prima di decidere se toccare questo valore.
Qui si parla addirittura di settare il valore a 1 [2]
>> 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.
Concordo, quando ho un po' di tempo farò alcuni approfondimenti su
quanto sopra. Grazie per gli spunti :)
> 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/
>
[0]
https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Encrypted_boot_partition_.28GRUB.29
[1] https://wiki.debian.org/SSDOptimization#Mounting_SSD_filesystems
[2]
https://wiki.debian.org/SSDOptimization#Adding_vm.swappiness_in_sysctl_for_the_kernel
Reply to: