[gl-como] domanda su partizionamento

pirla the.pirla@gdit.it
Ven 27 Giu 2008 16:32:43 CEST


Il giorno ven, 27/06/2008 alle 09.44 +0200, Riccardo (SCASI) ha scritto:
> Pirla tempo fa, iirc, ha scritto affermando che non partiziona i suoi 
> dischi ma utilizza lvm direttamente sul device (/dev/sda e non /dev/sda1 
> per intenderci).
> Questo per evitare il partizionamento del disco che, stando a quanto 
> dice, potrebbe causare rallentamenti se non fatto secondo certi canoni 
> (quali sono questi canoni, btw?).
> 
> Vorrei sapere se è possibile (e nel caso come) fare la stessa scelta 
> anche volendo utilizzare il raid sw di Linux.

Il raid sw, se fatto sui dischi, e non sui volumi, non risente del
fenomeno che ti andrò a spiegare (o meglio ne risente ma in misura molto
molto minore) e quindi va benissimo. E' la stessa cosa che creare un
filesystem direttamente sul device fisico e non su una sua partizione,
oppure usare LVM.
Anche LVM, se il PV viene creato sul volume fisico e non sulla
partizione guadagna in prestazioni.
Questo guadagno può essere trascurabile quando si tratta di un unico
dispositivo fisico (un unico disco per esempio) ma diventa importante
quando si tratta di dispositivi RAID (sia software che hardware) nei
quali lo stripe size è abbastanza grande.

La spiegazione a grandi linee è la seguente (e poi vi linko qualcosa da
cui prendere spunto per ricerche sul web).

Supponiamo di avere un dispositivo che fa striping e di avere uno stripe
element size di 128K (una bella potenza di 2). Supponiamo di avere 4
dischi in stipe, quindi lo stripe size risulta essere 128*4=512K (ancora
una potenza di 2)
supponiamo ora di creare una partizione su questo dispositivo, che il
sistema vede come un unico disco

fdisk bla bla bla
nessuno si sogna di premere la x quando fa un fdisk vero?
ok, fatta la mia partizione, io vado ad analizzarla e scopro che essa
parte da sessantatreesimo cilindro

Coooooosaaaaaaaaaaaaaaa

63 cilindri saltati? e per quale motivo?
ma 63 non è una potenza di 2
anzi mi sa che è una potenza di niente...
forse quando avremo computer che invece di avere i bit avranno i trit,
allora potrà avere un senso... anche se non ce l'ha.
quindi tutte le mie scritture in quella partizione (e anche in tutte
quelle che seguiranno questa sullo stesso dispositivo fisico) saranno
shiftate di 63 cilindri = 31,5 Kbyte

Bene... cosa vi fa pensare questo?
Io avrò un fenomeno che si chiama disk crossing sul device stripato,
oltre ad avere fenomeni analoghi su ogni singola meccanica impattata.
Il fenomeno più grave però è che la cache di questi sistemi, essendo
creata e progettata per loro, sarà composta da pagine che combaciano
esattamente con gli stripe element size o gli stripe size, il che
comporta un uso doppio della cache.
Ogni singolo IO del server (di una certa dimensione) genererà due IO
sullo storage e consumerà due pagine di cache. Il prefetching della
cache avrà un impatto devastante perché penserà che vengono fatte
letture o scritture sequenziali e riempirà la cache con dati che
probabilmente non servivano, degradando le performance generali dello
storage.

Solo per la cronaca i 63 cilindri scartati (e quindi inutilizzati) ce li
ritroviamo oggi solo per una compatibilità con qualcosa che risale agli
anni 80 

Non fatemi andare a cercare il perché di questi 63 cilindri saltati.

Riferimenti al fenomeno li trovate dappertutto cercando le parole chiave

Disk alignment offset
Linux partition offset alignmet
how to use diskpart to align offset
Setting the Alignment Offset on ESX Server and a (Virtual) Windows
Server
e così via

Alcuni riferimenti molto importanti sono

sul technet di microsoft http://technet.microsoft.com

http://clariionblogs.blogspot.com/2008/03/setting-alignment-offset-on-esx-server.html (interessante il blog in questione di cui non sapevo l'esistenza)

Alcune mail scambiate quà e la (mi pare interessare vedere la fonte)
http://www.mail-archive.com/linux-raid@vger.kernel.org/msg10148.html
In questa si intuisce abbastanza bene che anche su un disco solo c'è
qualche vantaggio.

Io per esperienza ho notato performance anche del 30% migliori dopo aver
fatto l'allineamento giusto.

A disposizione per ulteriori discussioni, spero di non avervi annoiato,
e di non aver detto cavolate

-- 
Ciao
        Pirla

Per rispondere in E-mail the (punto) pirla (chiocciola) gdit.it
*** un bacio ai pupi ***

---> Linux user since yesterday <---
--->     Linux User #389536     <---
-------------- parte successiva --------------
Un allegato non testuale è stato rimosso....
Nome:        non disponibile
Tipo:        application/pgp-signature
Dimensione:  189 bytes
Descrizione: Questa =?ISO-8859-1?Q?=E8?= una parte del messaggio
	firmata digitalmente
Url:         http://lists.linux.it/pipermail/gl-como/attachments/20080627/27f899e5/attachment.pgp 


Maggiori informazioni sulla lista gl-como