Newsgroup: it.comp.os.linux.iniziare
Titolo: GPT - UEFI - SSD - ADF

un bel po' di casini con la tecnologia che cambia, con le istruzioni 
che si trovano in rete a volte anche in contrasto tra loro...
qualcuno ha avuto problemi?
in pratica (almeno per me che non ho windows) funziona tutto anche 
ricorrendo al MBR e se le partizioni sui dischi non sono allineate, 
però è un peccato non sfruttare al massimo quanto disponibile...
-- 
bye
!(!1|1)
 
 

 qualcuno ha avuto problemi?
 
Io ho un SSD con GPT e parto con UEFI.
 
Mi ricordo che installare Ubuntu Oneiric in questo modo è stato un po' un 
casino, volendo fra l'altro mantenere il controllo delle operazioni (io 
faccio l'allineamento, io formatto il filesystem colle mie opzioni...).
 
Per la serie: installo, non va, mi chrooto dentro, sistemo...
 
Alla fine è andata, ma non saprei rifarlo al volo.
 
Il problema era che la mia scheda madre, se non usa UEFI per partire, al 
post mi fa aspettare 'na vita, scrive un paio d'errori su fantasmi di 
dischi... e poi parte, anche quaranta secondi dopo. Indipendentemente da 
come siano collegati i dischi, vuole proprio UEFI.
 
Ma se non hai problemi così, e non hai dischi supergrandi, puoi evitare 
GPT e quindi UEFI. Al limite potresti usare GPT anche con BIOS, ma ci 
vogliono dei trick.
-- 
Bye, Lem
Ceterum censeo ISLAM esse delendum
_________________________________________________________________
Non sprecare i cicli idle della tua CPU, né quelli della tua GPU.
 
http://www.worldcommunitygrid.org/index.jsp
 
http://www.rnaworld.de/rnaworld/
 
http://home.edges-grid.eu/home/
 
 
http://www.gpugrid.net/
 

 vogliono dei trick.
 
alla fine non dovrebbe essere neanche troppo complicato ora con tool 
come gpt fdisk (
http://www.rodsbooks.com/gdisk/index.html
)
 
il problema è andarsi a pescare tutte queste informazioni in rete e 
scremare tra i metodi superati e quelli applicabili alla situazione 
corrente (kernel, tool e hardware)
 
BTW ricordo il tuo thread sul malfunzionamento del discard (il trim 
automatico del SSD)
ora com'è la situazione ?
-- 
bye
!(!1|1)
 

 ora com'è la situazione ?
 
Guarda, sull'SSD di cui sto parlando adesso, che è proprio quello là, 
appunto avevo fatto l'ext4 senza journal (come suggerito da molte parti 
in rete). Solo poi ho scoperto che invece, senza il journal, discard non 
va... ma ormai ne avevo le scatole piene, l'ho lasciato così com'era, e 
invece dell'opzione discard ho usato e uso il comando fstrim in crontab, 
tutte le notti, e va benissimo uguale.
 
Sull'SSD del portatile ho messo invece un ext4 con journal, senza patemi, 
e buona notte al secchio. Così lì uso discard. :)
 
Naturalmente sugli SSD c'è ext4 sempre montato con noatime. Come 
scheduler: deadline[*] per tutti i dischi meccanici (passando a grub 
"elevator=deadline"), e poi noop per l'SSD ("echo noop > /sys/block/sda/
queue/scheduler" in /etc/rc.local). 
 
[*] che comunque è il second best per gli SSD.


 [*] che comunque è il second best per gli SSD.
 
scusa ma non ho capito...
usi deadline anche per i dischi meccanici?
e l'opzione del kernel nel default di grub non la puoi passare anche 
per noop senza modificare rc.local?
-- 
bye
!(!1|1)
 

 noop senza modificare rc.local?
 
L'opzione che passo a grub è per forza universale, e l'ioscheduler lì 
specificato vale per tutti i device.
 
Poi posso modificare l'ioscheduler di questo o quel singolo device, ma 
devo appunto farlo dopo. E /etc/rc.local mi è comodo per una cosa così.
 
Certo, potrei fare anche l'inverso: noop a grub, e deadline per gli altri 
in /etc/rc.local: sarebbe più sensato, perché il boot vien fatto usando 
solo l'SSD, che preferisce noop. Però l'SSD è uno, e quello resta, mentre 
gli altri dischi sono di più, e possono variare in numero e posizione. 
Quindi mi è più comodo fare come faccio.


 specificato vale per tutti i device.
 
giusto... mi era sfuggito questo piccolo particolare :-)
 
-- 
bye
!(!1|1)