DOMANDA Voglio installare Ubuntu su di una SSD cosa devo fare???

Pubblicità
guardare il wiki-bibbia di arch no?

trim si abilita con le opzioni di mount , il journal si disabilità quando crei il filesystem
 
spetta, per opzioni di mount intendi andare in fstab e mettere DISCARD ?

la bibbia che dici tu l'ho trovata, però naturalmente è talebana: https://wiki.archlinux.org/index.php/Solid_State_Drives_%28Italiano%29

l'allineamento delle partizioni in concreto non riesco a capire come avolo faccio a farlo,
il trim alla fine spiega uguale e più complicata di quella che ho trovato io ed il journaling me pare che manco dice come disattivarlo.

somma, ci capisco meno di prima, e l'ssd mi arriva domani (o meglio oggi dopo la nanna) :cav:
 
allora, per capirci bene, mettiamo tuti i passaggi compresi quelli scemi:

installo l'ssd
uso GPT (non ho capito come) e mi allinea automaticamente le partizioni (crea anche la partizione di boot 1MiB necessaria ?)
installo l'OS con partizioni ext4.
rimuovo il journaling (solo su root o anche su home ? )
attivo il TRIM (in che punto scrivo discard con l'editor ? oppure posso fidarmi a dargli da terminale discard /dev/sda*** )


se devo cambiare anche lo scheduler, devo prima capire cos'è :cav:

chiedo scusa per il livello molto noobish.
credo che però in fondo possiate capirmi: se canno rischio di mandare in fumo circa 100 euro dell'ssd.
 
Guarda se aspetti domani (arriva pure a me un SSD) provo ad installare OpenSuse e vedo cosa fa da solo e cosa c'è da fare a manina.

Rimuovi il journaling pure sulla /home. Per attivare il TRIM (a meno che non ci pensi già OpenSuse), bisognerà modificare /etc/fstab. (Meglio attivare anche l'opzione noatime)

Riguardo allo scheduler: è una parte del sistema operativo (a fare i pignoli del kernel) che si occupa di "organizzare" le scritture e le letture sul disco. Quello di default va bene per i dischi rigidi perché cerca di ridurre le latenze dovute allo spostamento dalla testina, sull'SSD non ci sono parti meccaniche e quindi la "riorganizzazione" non serve. Questo quello che ho capito io a grandi linee, non ho mai approfondito. Se ho scritto castronerie correggetemi.
 


qua sopra gparted ( disponibile da live in ubuntu ) , la voce evidenziata è quella che interessa a te, seleziona gpt
per lo schema di partizionamento :
https://wiki.archlinux.org/index.php/GUID_Partition_Table#BIOS_systems
in sintesi ti basta una partizione da 2MB
e tip per grub
https://wiki.archlinux.org/index.php/GRUB#GPT_specific_instructions



infine, a sistema avviato devi editare un file /etc/fstab così


- - - Updated - - -

prima che ci sputi .. queste sono frociate da "nerdoni" ..

ubuntu riconosce dove va e si adatta a misura
 
Riguardo allo scheduler: è una parte del sistema operativo (a fare i pignoli del kernel) che si occupa di "organizzare" le scritture e le letture sul disco. Quello di default va bene per i dischi rigidi perché cerca di ridurre le latenze dovute allo spostamento dalla testina, sull'SSD non ci sono parti meccaniche e quindi la "riorganizzazione" non serve. Questo quello che ho capito io a grandi linee, non ho mai approfondito. Se ho scritto castronerie correggetemi.

Corretto. Infatti lo scheduler no-op usa una teoria conosciuta come FIFO (First In, First Out), quindi il primo dato che richiede la scrittura sarà il primo ad essere scritto.
Infatti, proprio per il suo funzionamento, è ritenuto il più semplice scheduler sul kernel Linux. Tant'è che c'è anche chi NON lo considera uno scheduler, ma semplicemente una coda.

Il deadline non so precisamente come funziona, però so che distribuisce le risorse ad ogni richiesta per un determinato periodo di tempo (proprio per questo deadline).
Se non ricordo male il deadline di base è di 5 secondi, quindi se viene richiesta la lettura O la scrittura (lo scheduler gestisce 2 code, una per la scrittura e una per la lettura) appena scatta il 5° secondo le risorse vengono indirizzate ad altro.
Non è difficile capire che tra i due il migliore, contando la velocità di un moderno SSD, sia il no op per via della sua semplicità.

Edit: sono 5 secondi per la scrittura e 500ms per la scrittura. :D

- - - Updated - - -

prima che ci sputi .. queste sono frociate da "nerdoni" ..

Approposito di frociate da nerdoni, hai visto che su Arch gnome 3.6 è ancora in gnome-unstable per via della dipendenza da systemd? :lol:
 
Guarda se aspetti domani (arriva pure a me un SSD) provo ad installare OpenSuse e vedo cosa fa da solo e cosa c'è da fare a manina.

benissimo, allora aspetto un tuo parere prima di metterci mano ;)

cmq a furia di sbatterci sopra la testa, mi pare che i vari passaggi incomincino ad avere un senso.
per quanto riguarda lo scheduler, se va bene quanto riportato qui per grub2 sono a posto:
Ottimizzazioni Per I Dischi SSD




lascio invece la parola all'onorevole @centoventicinque sulla belle scritta rossa della bibbia:
Create the 2MiB partition mentioned above BEFORE you convert to GPT. If you do not, gparted will not resize your boot partition to allow its creation, and when you reboot GRUB2 will not know where to look.

ok, la partizione va creata prima e qui nessun problema, il concetto è chiaro.

la cosa che lascia un attimo disorientato, è se è obbligatorio usare un altro programma.
sulla guida si parla di cgdisk or GNU Parted.
 
gparted è il front-end per gnu parted :)
gdisk è la versione " gpt" di fdisk
parted ..è parted :lol:

gparted è grafico , gli altri a linea di comando.. scegli tu
 
dogma ha detto:
benissimo, allora aspetto un tuo parere prima di metterci mano ;)

cmq a furia di sbatterci sopra la testa, mi pare che i vari passaggi incomincino ad avere un senso.
per quanto riguarda lo scheduler, se va bene quanto riportato qui per grub2 sono a posto:
Ottimizzazioni Per I Dischi SSD

lascio invece la parola all'onorevole @centoventicinque sulla belle scritta rossa della bibbia:
Create the 2MiB partition mentioned above BEFORE you convert to GPT. If you do not, gparted will not resize your boot partition to allow its creation, and when you reboot GRUB2 will not know where to look.

Va bene la guida. Ma i passaggi riguardanti il bootloader vanno modificati, in quanto ormai tutte le maggiori distro usano grub2.
E se usi sia un SSD che un HDD conviene usare il no-op solo su quello.
Come puoi vedere nella guida dice chiaramente che usa 2 SSD, quindi a lui basta solo uno scheduler.

Se non lo fa qualcun'altro, appena sono a casa ti modifico quel che serve. ;)

Permalink
 
ti ringrazio.
però in fondo mi sembra che descrive anche quello del grub2.
scheduler ne ho bisogno anch'io di uno solo, dato che tengo solo l'SSD: per lo storage tengo un hd esterno.
 
ti ringrazio.
però in fondo mi sembra che descrive anche quello del grub2.
scheduler ne ho bisogno anch'io di uno solo, dato che tengo solo l'SSD: per lo storage tengo un hd esterno.

Cavoli, mi ero dimenticato di parecchi post. :cav:
Comunque, il file menu.lst era tipico di grub legacy (o 1 che dir si voglia). Su grub 2 c'è il file grub.cfg. Che NON deve essere modificato. In realtà si può, ma è molto simile ad uno script, quindi si rischia davvero di rovinare qualcosa mettendo un punto di troppo nel punto sbagliato. Per questo esiste il file /etc/default/grub che permette di aggiungere ciò che serve e il comando (almeno su ubuntu) update-grub che ricrea grub.cfg.

Volendo puoi anche configurare grub.cfg come in grub1, ma è sconsigliato, nonchè deprecato.
In più un aggiornamento del kernel porterebbe a ricreare la configurazione, quindi perederesti il file.

apri il file /etc/default/grub (ovviamente con diritti di amministratore e se vuoi con un editor grafico, tipo gedit) e inserisci in fondo alla linea GRUB_CMDLINE_LINUX_DEFAULT="foo foo foo", dentro le virgolette, elevator=noop , ovviamente senza modificare altro.
In pratica deve diventare così:

GRUB_CMDLINE_LINUX_DEFAULT="foo foo foo elevator=noop"

Dopodichè, dai update-grub da root.

Foo è una convenzione profondamente nerdica che indica di sostituire il termine con ciò che si trova lì.
Ovviamente le voci potrebbero essere di più. Comunque se non erro ubuntu di default ne usa 3: ro (monta il filesystem in sola lettura e lo rimonta in lettura/scrittura dopo, in questo modo si sfruttano le opzioni contenute in fstab) quiet (NON mostra l'ouput del kernel e di varie cose, se si fa un boot testuale) splash (mostra la splashscreen, in questo caso plymouth). :D

Avrei un dubbio, e quindi invoco l'aiuto di @centoventicinque.
Non avendo un SSD, non ho mai avuto la necessità di usare particolari opzioni, tu per caso hai usato da qualche parte l'opzione commit=*?

Se centoventicinque risponde di no, o quando applichi il tutto non ha risposto, salta il punto in cui dice di aggiungere commit=100 in /boot/grub/menu.lst
 
Ultima modifica:
Pubblicità
Pubblicità
Indietro
Top