View Full Version : [FEDORA] Necessario allineare le partizioni su SSD? Come partizionare al meglio?
Spiego meglio il mio dubbio. Ho da installare Fedora 21 x64 su un portatile con Crucial MX200 250GB.
Ora nelle info di installazione di FedoraOnline QUI (http://doc.fedoraonline.it/Configurare_un_SSD) viene indicata una procedura di allineamento delle partizioni.
Cercando in rete l'EBS ho contattato la Crucial che ha dichiarato non necessaria nessuna procedura particolare in quanto TRIM e GarbageCollection sono implementate e attive sulla mia unità.
Mi sono imbattuto su diversi thread stranieri in cui i pareri sono contrastanti.
Infine ho trovato un articolo del wiki di ArckLinux QUI (https://wiki.archlinux.org/index.php/Partitioning_%28Italiano%29) in cui si parla di non far affidamento ad alcune guide del 2007/2009, in quanto non aggiornate, in cui si parla di allineare con CHS.
Tirando le somme... bisogna allineare o no? Uso GParted Live 19. Va bene o no?
Per provare ho creato 3 partizioni:
/boot/uefi
/home
/
non so per quale motivo ma l'installer di fedora le ha ritenute non valide e le ho dovute rifare con suo tool.
A me servirebbe un partizionamento tipo quello sopra, non so però se conviene utilizzare UEFI o MBR. Le differenze credo non influiscano sulle prestazioni.
Non utilizzo swap in quanto ho 8gb di ram e presto saranno 16. In più monterò un hdd caddy al posto del dvd per un ssd di solo storage ;)
ishtar1900
26-09-2015, 13:23
Se il pc è recente ti consiglio UEFI piuttosto che bios , quindi allineare e partizionare in gpt, creare ovviamente la partizione uefi, ecc., su questo però credo dovrai fare riferimento alla wiki di fedora su come installare la distro con avvio da uefi, o magari qualche utente che la usa potra esserti d'aiuto.
In ogni caso per rispondere al tuo quesito, indipendentemente dalle "scuole di pensiero" alternative, per quanto ne so, allineare le partizioni dell'ssd è consigliabile, quindi io l'ho sempre fatto.
Per l'ESB, come da wiki di arch:
" Se non si conosce l'EBS del proprio SSD, è comunque possibile usare una dimensione di 512 KiB (o 1024 KiB se si vuole essere sicuri e non ci si preoccupa di perdere il primo MiB del proprio disco). Queste dimensioni sono maggiori o uguali di tutti i correnti EBS. Allineare le partizioni per l'EBS produrrà partizioni allineate anche per dimensioni più piccole."
pabloski
27-09-2015, 09:54
Cercando in rete l'EBS ho contattato la Crucial che ha dichiarato non necessaria nessuna procedura particolare in quanto TRIM e GarbageCollection sono implementate e attive sulla mia unità.
Si ok, ma la write amplification aumenta se le partizioni non sono allineate.
In ogni caso, tutti i tool ( fdisk, gdisk, gparted ) presenti nelle versioni recenti di qualsiasi distribuzione linux effettuano il rounding ad 1 MB. Quindi l'allineamento avviene automaticamente ( a meno che il tuo SSD non abbia dimensioni di blocco strane e/o superiori ad 1 MB, praticamente nessun SSD in commercio è così ).
Infine ho trovato un articolo del wiki di ArckLinux QUI (https://wiki.archlinux.org/index.php/Partitioning_%28Italiano%29) in cui si parla di non far affidamento ad alcune guide del 2007/2009, in
quanto non aggiornate, in cui si parla di allineare con CHS.
CHS è morto e sepolto. Usa Gparted e non avrai nessun genere di problemi.
Ovviamente se il tuo pc usa UEFI non ha senso non usare GPT ( 128 partizioni contro le 4 del MBR ).
non so per quale motivo ma l'installer di fedora le ha ritenute non valide e le ho dovute rifare con suo tool.
Può darsi che tu abbia sbagliato a settare il tipo di partizione. E comunque dev'essere /boot/EFI e non /boot/uefi. Occhio che Fedora usa LVM di default, per cui è possibile che si stia lamentando del fatto che cerchi di costringerla ad installarsi sul disco fisico.
A me servirebbe un partizionamento tipo quello sopra, non so però se conviene utilizzare UEFI o MBR. Le differenze credo non influiscano sulle prestazioni.
No, le prestazioni non cambiano. Il SSD è sempre quello e da quando i nuovi firmware fanno uso massiccio di garbage collection, trim, compressione al volo dei dati, deduplicazione, ecc... Ma del resto se riescono a far durare il SSD sotto Windows ( che scrive dati di continuo )...
Grazie molte ad entrambi, userò il wiki di Arh per partizionare in quanto quello di Fedora è palesemente obsoleto parlando di CHS...
@ishtar1900: cosa usi per partizioni e allineamento?
per la procedura uefi ci sono già, installo su Latitude E5530
ishtar1900
27-09-2015, 18:41
Grazie molte ad entrambi, userò il wiki di Arh per partizionare in quanto quello di Fedora è palesemente obsoleto parlando di CHS...
@ishtar1900: cosa usi per partizioni e allineamento?
per la procedura uefi ci sono già, installo su Latitude E5530
gparted ( ultima versione è la 0.23 ) è estremamente comodo, per allineare basta scegliere align to MiB e dare il valore 1, prima però crei la tavola delle partizioni, GPT nel caso volessi seguire il nostro consiglio, poi partizione efi , le altre in ext4 ( altrimenti il trim non va). Io non creo la swap perchè l'ibernazione non la uso e 8gb di ram sono piu che sufficienti. Mi raccomando dal bios del pc abilita l'AHCI se non è gia abilitato, e a sistema installato aggiungi alle opzioni di mount delle partizioni di sistema (cartella fstab) discard ( per il trim) e noatime , ci sarebbero altre opzioni ma dovrai valutarle tu, basta fare una ricerca su google.
gparted ( ultima versione è la 0.23 ) è estremamente comodo, per allineare basta scegliere align to MiB e dare il valore 1, prima però crei la tavola delle partizioni, GPT nel caso volessi seguire il nostro consiglio, poi partizione efi , le altre in ext4 ( altrimenti il trim non va). Io non creo la swap perchè l'ibernazione non la uso e 8gb di ram sono piu che sufficienti. Mi raccomando dal bios del pc abilita l'AHCI se non è gia abilitato, e a sistema installato aggiungi alle opzioni di mount delle partizioni di sistema (cartella fstab) discard ( per il trim) e noatime , ci sarebbero altre opzioni ma dovrai valutarle tu, basta fare una ricerca su google.
si conoscevo gia le opzioni, uso al momento Mageia su un altro note e le partizioni sembrano allineato con il comando blockdev --getalignoff, ma il trim sembra ormai non funzionare più (le partizioni sono tutte ext4), tanto che devo farlo manualmente con fstrim, non so il motivo. Le prestazioni si sono degradate in modo assurdo, sarà che forse lo uso anche come storage e si è riempito oltre il 70%.
Come schema di partizioni cosa mi consigliate?
- boot/efi
- /
- /home
e cos'altro?
Uso solo la sospensione, non l'ibernazione, quindi credo che 8gb di ram per il suspend to ram siano sufficienti senza partizione di swap.
Il mio ideale sarebbe quello di mettere un secondo SSD su caddy dvd e su questo mettere DATI, /var, /swap(eventualmente).
Altra cosa. LVM è necessario? Mi stavo informando ora su come funziona.
pabloski
28-09-2015, 10:44
ma il trim sembra ormai non funzionare più (le partizioni sono tutte ext4), tanto che devo farlo manualmente con fstrim, non so il motivo.
Ci sono dietro specifiche scelte degli sviluppatori. Il TRIM è disabilitato di default e va abilitato tramite l'opzione discard nel file /etc/fstab.
Loro consigliano però di creare un cronjob che esegua periodicamente fstrim.
Le prestazioni si sono degradate in modo assurdo, sarà che forse lo uso anche come storage e si è riempito oltre il 70%.
70% è parecchio per un dispositivo che bara spostando i dati da una cella di memoria all'altra per farle consumare tutte allo stesso modo
chiaramente dipende pure dal tipo di SSD ( Intel, Samsung, Crucial usano firmware molto intelligenti )
Come schema di partizioni cosa mi consigliate?
- boot/efi
- /
- /home
Direi nient'altro. La home è separata e quindi si può reinstallare l'OS senza perdere dati ed impostazioni. Il mountpoint per la ESP pure c'è.
Uso solo la sospensione, non l'ibernazione, quindi credo che 8gb di ram per il suspend to ram siano sufficienti senza partizione di swap.
Mai avuto problemi in questo senso.
Il mio ideale sarebbe quello di mettere un secondo SSD su caddy dvd e su questo mettere DATI, /var, /swap(eventualmente).
Con 8 GB di ram è difficile che userai mai lo swap ( a meno che non fai rendering per conto della Pixar ).
Altra cosa. LVM è necessario? Mi stavo informando ora su come funziona.
No, ma è comodo. Poter aggiungere/togliere interi dischi al volo, ridimensionare i volumi, spostarli, cancellarli, ecc... il tutto in un'instante, è un bell'extra.
Ci sono dietro specifiche scelte degli sviluppatori. Il TRIM è disabilitato di default e va abilitato tramite l'opzione discard nel file /etc/fstab.
Loro consigliano però di creare un cronjob che esegua periodicamente fstrim.
Uso Intel 320 160GB. Le opzioni su Fstab sono gia abilitate dall'inizio (noatime, discard).
La cosa che più mi lascia perplesso è che all'inizio la procedura di verifica con hdparm per verificare su un settore veniva cancellato dal trim veniva effettua con successo.
Non capisco il perchè il trim non funzioni più :confused:
Cmq sia, come posso fare per creare un cronjob?
Con 8 GB di ram è difficile che userai mai lo swap ( a meno che non fai rendering per conto della Pixar ).
No nessun rendering pixar ;) solo qualche macchina virtuale. Userò il secondo SSD per mettere DATI e /var cosi da limitare gli accessi sul principale per cartelle/file temporanei
ishtar1900
28-09-2015, 13:56
. Userò il secondo SSD per mettere DATI e /var cosi da limitare gli accessi sul principale per cartelle/file temporanei
Per i dati ( download/film/serie Tv,ecc) anch'io uso un hd meccanico, la cartella /var non è necessario spostarla, io l'ho sempre lasciata sull'ssd, importante è limitare la sua dimensione, metti il journald a 50mb ( /etc/systemd/journald.conf opzione SystemMaxUse=50M), volendo puoi anche disabilitarlo del tutto, poi svuoti spesso la cache di pacman (il gestore pacchetti della distro che uso, visto che tu userai fedora, credo sia DNF nelle nuove versioni, prima c'era yum), non sono comunque applicazioni che "consumano" il disco eccessivamente.
pabloski
28-09-2015, 14:09
Uso Intel 320 160GB. Le opzioni su Fstab sono gia abilitate dall'inizio (noatime, discard).
La cosa che più mi lascia perplesso è che all'inizio la procedura di verifica con hdparm per verificare su un settore veniva cancellato dal trim veniva effettua con successo.
Sono perplesso. Specificando discard nel fstab dovrebbe effettuare il trim senza problemi.
Per verificare potresti dare il comando
dmesg | grep discard
hdparm ti può dire se la periferica fisica supporta il trim, ma non se il filesystem lo sta usando
un'altro metodo è di dare mount e verificare che sia presente discard nelle opzioni di mount dell'unità relativa
Cmq sia, come posso fare per creare un cronjob?
Si può fare editando /etc/crontab, ma suppongo che fedora installi di default la GUI gnome-schedule.
Ma ti conviene prima determinare se riesce o meno ad usare il trim, perchè è decisamente strano che l'opzione discard non faccia il suo lavoro.
p.s. per verificare con certezza se funge il trim, usa questo metodo http://unix.stackexchange.com/questions/85865/trim-with-lvm-and-dm-crypt/85880#85880
Per i dati ( download/film/serie Tv,ecc) anch'io uso un hd meccanico, la cartella /var non è necessario spostarla, io l'ho sempre lasciata sull'ssd, importante è limitare la sua dimensione, metti il journald a 50mb ( /etc/systemd/journald.conf opzione SystemMaxUse=50M), volendo puoi anche disabilitarlo del tutto, poi svuoti spesso la cache di pacman (il gestore pacchetti della distro che uso, visto che tu userai fedora, credo sia DNF nelle nuove versioni, prima c'era yum), non sono comunque applicazioni che "consumano" il disco eccessivamente.
Ho impostato su Mageia al momento il journald a 50M. Vediamo se qualcosa cambia..
La cache URPMI non ho trovato come svuotarla.
Userò con Mageia 21 ancora YUM, DNF non c'è e ancora non lo conosco.
Sono perplesso. Specificando discard nel fstab dovrebbe effettuare il trim senza problemi.
Per verificare potresti dare il comando
dmesg | grep discard
Sembra proprio attivo..
http://oi57.tinypic.com/35ldkq1.jpg
hdparm ti può dire se la periferica fisica supporta il trim, ma non se il filesystem lo sta usando
un'altro metodo è di dare mount e verificare che sia presente discard nelle opzioni di mount dell'unità relativa
Anche qui presente su /dev/sda5 (/) e /dev/sda6 (/home). Vuoi uno screen?
Si può fare editando /etc/crontab, ma suppongo che fedora installi di default la GUI gnome-schedule.
Uso Fedora KDE, non mi piace Gnome. Ho apertto con nano ma non so cosa editare, o meglio come aggiungere un job.
Basta mettere il comando sull'ultima riga?
Ma ti conviene prima determinare se riesce o meno ad usare il trim, perchè è decisamente strano che l'opzione discard non faccia il suo lavoro.
p.s. per verificare con certezza se funge il trim, usa questo metodo http://unix.stackexchange.com/questions/85865/trim-with-lvm-and-dm-crypt/85880#85880
Fatta la procedura cosi come descritta e il pattern risulta 0, in quanto il disco non ha encryption.
Sarà che il calo delle prestazioni sia dovuto alle scritture o alla % di riempimento?
Onestamente sono rimasto scontento delle prestazioni da un anno a questa parte. Arranca di brutto..
pabloski
29-09-2015, 08:41
Basta mettere il comando sull'ultima riga?
Magari. La sintassi è decisamente più criptica. Comunque per KDE esiste Kcron ( non so se fedora lo installi di default o meno ).
Sarà che il calo delle prestazioni sia dovuto alle scritture o alla % di riempimento?
Considerando tutte le informazioni che hai postato, direi che il problema di sicuro non è la mancanza del TRIM.
Il sistema operativo sta usando la funzionalità correttamente, per cui mi verrebbe da pensare a problemi del firmware del SSD o proprio una sorta di "normale usura" degli SSD Intel.
Guardando la pagina relativa sul sito Intel ho notato una cosa http://ark.intel.com/it/products/56563/Intel-SSD-320-Series-120GB-2_5in-SATA-3Gbs-25nm-MLC
Scrittura random (span 100%) 400 IOPS
Noterai il calo dell'IOPS da 14000 a 400. Il caso 400 è riferito a quando il SSD ha la stragrande maggioranza dello spazio occupato.
L'altra cosa ( positiva ) che ho notato è che è un MLC, per cui non perde celle di memoria alla stessa velocità con cui uno affetto da calvizie perde i capelli.
Magari. La sintassi è decisamente più criptica. Comunque per KDE esiste Kcron ( non so se fedora lo installi di default o meno ).
Dovrò documentarmi in rete. Penso ce ne sia di roba su crontab e Kcron :)
Considerando tutte le informazioni che hai postato, direi che il problema di sicuro non è la mancanza del TRIM.
Il sistema operativo sta usando la funzionalità correttamente, per cui mi verrebbe da pensare a problemi del firmware del SSD o proprio una sorta di "normale usura" degli SSD Intel.
Guardando la pagina relativa sul sito Intel ho notato una cosa http://ark.intel.com/it/products/56563/Intel-SSD-320-Series-120GB-2_5in-SATA-3Gbs-25nm-MLC
Scrittura random (span 100%) 400 IOPS
Noterai il calo dell'IOPS da 14000 a 400. Il caso 400 è riferito a quando il SSD ha la stragrande maggioranza dello spazio occupato.
L'altra cosa ( positiva ) che ho notato è che è un MLC, per cui non perde celle di memoria alla stessa velocità con cui uno affetto da calvizie perde i capelli.
Si a questo punto lo penso anche io. Probabile sia proprio questione di firmware o degrado prestazionale.
Ieri sera sono riuscito a installare Fedora 21 KDE finalmente sul nuovo note. Ho allineato con gdisk a 2048 settori quindi a 1024KB. Credo sia molto meglio di GParted.
Partizioni:
/boot/efi ---> 200MB
/ ---> 80GB
/home ---> 150GB
Spero vada bene. Poi in futuro spero di riuscire a spostare /var e altre cartelle su SSD esterno e limitarne la capacità massima.
Se riesco vedo se riesco a fare qualche bench con l'SSD.
Vi ringrazio ancora una volta per il grande supporto dato. Vi sono veramente grato. :) :flower:
# cat /etc/cron.weekly/fstrim
#!/bin/bash
# this cronjob will discard unused blocks on the SSD mounted filesystems
# get the locally mounted block devices - those starting with "/dev:
# run df -k, pipe the result through grep and save the sixth field in
# in the mountpoint array
mountpoint=( $(df -l | grep ^/dev | awk '{print $6}') )
# loop through the array and run fstrim on every mountpoint
for i in "${mountpoint[@]}"
do
/sbin/fstrim -v $i;
done
Ricordatevi che se e' un portatile o una workstation che non fa 24/7 dovete farci girare anacron oltre a cron.
# cat /etc/cron.weekly/fstrim
#!/bin/bash
# this cronjob will discard unused blocks on the SSD mounted filesystems
# get the locally mounted block devices - those starting with "/dev:
# run df -k, pipe the result through grep and save the sixth field in
# in the mountpoint array
mountpoint=( $(df -l | grep ^/dev | awk '{print $6}') )
# loop through the array and run fstrim on every mountpoint
for i in "${mountpoint[@]}"
do
/sbin/fstrim -v $i;
done
Ricordatevi che se e' un portatile o una workstation che non fa 24/7 dovete farci girare anacron oltre a cron.
Devo informarmi meglio sui 2 comandi, non li conosco bene.
Quindi il file è in etc/cron.weekly/fstrim?
Volevo anche modificare lo scheduler del kernel, spostare le cartelle /var e /tmp, spostare i profili dei browser(firefox) in /tmpfs, cosi come ho letto nel wiki di Arch, cosa ne dite?
Per il momento TRIM attivato e funzionante dalle verifiche fatte, anche se le prestazioni non sono da urlo (MX200).
Devo informarmi meglio sui 2 comandi, non li conosco bene.
Quindi il file è in etc/cron.weekly/fstrim?
Si, direi che una volta a settimana il trim va bene.
Farlo continuamente mettendo discard nelle opzioni di mount non mi sembra furbo.
Volevo anche modificare lo scheduler del kernel, spostare le cartelle /var e /tmp, spostare i profili dei browser(firefox) in /tmpfs, cosi come ho letto nel wiki di Arch, cosa ne dite?
Sicuramente la RAM e' sempre piu' veloce dell'SSD, e non fai scritture inutili.
Si, direi che una volta a settimana il trim va bene.
Farlo continuamente mettendo discard nelle opzioni di mount non mi sembra furbo.
Perchè? Guide ufficiali lo consigliano. Hai qualche motivo fondato per dire ciò o è solo una tua opinione?
Sicuramente la RAM e' sempre piu' veloce dell'SSD, e non fai scritture inutili.
Già, solo che ancora non so bene come fare :stordita:
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.