Teoria del disco: Dimensione del Cluster?

[BlueKnight]

Ciao a tutti,
siccome devo fortmattare il mio HD volevo sapere se quello a cui avevo pensato fosse corretto oppure mi son sbagliato su tutta la linea;

Normalmente Windows XP nella formattazione da un valore di 4Kb ai cluster della partizione, che dovrebbero essere un compromesso fra velocità della testina/dimensione dei file allocati nei cluster.
Per velocizzare il sistema e il file di paging intendevo fare e solitamnte faccio la partizione C: che va dai 10GB ai 15GB.
Ora mi chiedo, ma non sarebbe meglio effettuare la formattazione a 64Kb e poi fare un discorso simili per quello che sono i nuovi dischi con Perpendicular Recording?
Nel senso, stiamo parlando della partizione di C: che solitmante si trova verso la parte + sterna del piatto, quindi quello che garantische maggiore velocità di lettura da parte della testina e maggior rotazione del piatto in rapporto alla circonferenza: quindi maggiore superficie letta a parità di tempo rispetto una porzione del piatto più accentrata.

Quello che penso io è che mettendo 64k in un cluster la velocità di lettura di un file da 1GB per esempio non frammentato risulterà più veloce, per cui anche il file di paging diventerà più veloce. QUesto è vero, dovrebbe portare come funziona per i dischi perpendicular recording a tempi di accesso maggiori visto che per leggere un settore ci vuole più tempo, e ora che la testina trova il settore giusto perdo altro tempo...ma contango che la partizione C risulta sulla prima parte del piatto verso l'esterno e che la partzione non è grossa...non si avrebbero lo stesso dei vantaggi con cluster di 64K? Inoltre anche se i tempi di lettura aumentano con cluster così grossi, non penso che la cosa sia più lenta rispetto a quello che è un vero e proprio spostamento meccanico della testina per andare a leggere i vari settori.

Voin che formattazione usate? La mia teoria ha qualche pecca ed è errata in qualcosa? Allocare un elevato numero di informazioni in un solo settore come posson esser 64K può portare a una più facile perdita di dati o danneggiamento di un settore come può essere l'overburn su un CD?

Grazie e ciao

[=Cipo2003=]

Originariamente inviato da BlueKnight

Quello che penso io è che mettendo 64k in un cluster ...

secondo me facendo così crei un cluster di 64k, cioè più lungo, più grande, non metti 64k nello spazio fisico dove prima cene stavano 4, altrimenti potremmo aumentare le capacitaà dei nostri dischi di x16

penso che la scelta migliore sia da fare in base all'uso che se ne fa del disco,

files piccoli>>cluster piccoli
files grandi>>cluster grandi

correggietemi se sbaglio che non ne so bene fi filesystems a livello così basso...

[CRL]

Una cosa che non hai considerato è la dimensione media delle richieste fatta al disco. In genere, su una partizione con s.o., le richieste sono molto piccole, io ho riscontrato una grossa predominanza di 16kB e 32kB, e quindi fissare una dimensione a 64kB mi pare troppo elevato, perchè perdiamo tempo oltre che un po' di spazio, ma di questo potremmo anche fregarcene.
Credo che il ragionamento di aumentare la dimensione dell'unità base sia sicuramente a vantaggio delle prestazioni, ma non mi spingerei oltre i 16kB, per i discorsi fatti.
Non mi aspetterei poi nulla di tangibile a livello di prestazioni, forse il gioco non vale la candela, ma vale la pena provare.

C'è una persona che è molto preparata in queste cose, provo a chiederle di intervenire.

- CRL -

[repne scasb]

Per cluster si intende usualmente la minima unita' di allocazione di cui dispone il file sistem. In generale e' un multiplo potenza di 2 della dimensione di un settore fisico del disco.

Piu' grande e' un cluster piu' grande sara' lo spazio perso per l'allocazione dei file presenti sul disco rigido (essendo la minima unita' di allocazione un file di 1 byte occupera' esattamente 1 cluster, ed essendo 1 cluster piu' grande di 1 byte il resto e' spazio perso (wasted space).

Piu' grande e' un cluster piu' piccolo e' "in generale" l'overhead del file sistem nelle operazioni di "ricerca/caricamento/salvataggio" di un file nel nostro hard-disk. Un hard-disk di 1Gb formattato FAT32 con cluster di 512Bytes, ogni copia delle 2 FAT occupera' 1000000000/512*4/512=15258 settori, se formattato con cluster di 4096 Bytes occupera' 1000000000/4096*4/512=1907 settori.

Piu' grande e' un cluster, piu' tempo sara' necessario per riposizionare il disco sul file successivo a parita' di frammentazione; e' necessario un esempio chiarificatore:

Si supponda di avere nel disco 3 file rispettivamente di 400/1700/3000 Bytes, non frammentati, con cluster di 512 Bytes avremo ('1' settori occopati dal file 1, '2' settori occupati dal file 2, '3' settori occupati dal file 3, 'X' settori occupati da nulla):

12222333333

Con cluster da 1024 Bytes:

1X2222333333

Con CLuster da 2048 Bytes:

1XXX2222333333XX

Con cluster da 4096 Bytes:

1XXXXXXX2222XXXX333333XX

E' chiaro che all'aumentare della dimensione di un cluster maggiore sara' lo spazio perso e maggiore sara' lo spostamento in lettura/scrittura che un disco subira'.

In sostanza piu' piccolo e' un cluster maggiormente sara' sfruttata la cache di un moderno disco rigido.

A questo punto sembrerebbe conveniente ridurre la dimensione di un cluster a quella di un settore se non fosse che il livello di frammentazione di un disco aumenta "piu' che linearmente" al diminuire della dimensione di un cluster, ossia:

Piu' piccolo e' un cluster piu' e' elevata e' la probabilita' di frammentazione, piu' un disco e' frammentato piu' elevate saranno le operazioni di I/O necessarie per leggere/scrivere tale file (e' necessaria almeno 1 lettura/scrittura/posizionamento per ogni frammento).

Da tutto cio' si evince che le prestazioni di un disco in funzione della dimensione dei cluster del file sistem, e una funzione composta da due quantita' antagoniste(1)(2)<->(3):

1) Convengono cluster grandi in quanto si risparmia in overhead del file sistem
2) Convengono cluster grandi in quanto piu' bassa sara' la probabilita di frammentazione.
3) Convengono cluster piccoli in quanto i file saranno maggiormente impacchettati con maggior sfruttamento della cache del disco rigido

E' quindi chiaro che non conviene avere cluster ne piccoli ne grandi ma "ottimali". Per trovare la dimensione ottimale di un cluster si esegua la seguente "approssimata" quanto banale operazione:

Si calcolo lo spazio occupato dai file presenti sul disco rigido (non lo spazio occupato dai cluster, 2 file da 1 byte hanno un occupazione di 2 bytes), si divida tale quantita' per il numero di file presenti sul disco e si moltiplichi per 32 (32 cluster/frammenti massimi per file), si trovi la potenza di due moltiplicato per la dimensione di un settore del disco (512 bytes) piu' vicina a tale quantita': tale potenza di due sara' la dimensione ottimale dei cluster del "nostro" particolare hard-disk (e' un approccio rudimentale che puo' dare risultati errati in qualche caso in quanto piu' che una media sarebbe necessaria un distribuzione).

[BlueKnight]

Cavolo, sto facendo molta fatica a capire il tuo trattato, anche se è molto esaustivo!

Puoi farmi un esempio di calcolo della tua ultima descrizione, il "metodo rudimentale" per intenderci.

In ogni caso stando al fatto delle varianti, sembra essere preferibile avere un cluster più grande piuttosto che più piccolo.

Non ho capito una cosa però, dalla tua descrizione sembra che non abbia detto caxxate, ma mettendo i cluster grandi 64K, vuol dire che su un settore l'HD va a allocare e storare fino a 64Kb di contenuti? Perchè un entente mi sembra abbia ipotizzato una cosa differente.

Ciao e grazie

[repne scasb]

Originariamente inviato da BlueKnight

Puoi farmi un esempio di calcolo della tua ultima descrizione, il "metodo rudimentale" per intenderci.

Dal prompt di WindowsXP dare i seguenti comandi (per il disco C:

CD\
DIR /S

Nel mio caso ho: 44101 files occupanti lo spazio di 5889226675. Ora 5889226675/44101=133539 e 133539/32=4173. Nel mio caso un cluster ottimale sta intorno a 4KBytes.

Non ho capito una cosa però, dalla tua descrizione sembra che non abbia detto caxxate, ma mettendo i cluster grandi 64K, vuol dire che su un settore l'HD va a allocare e storare fino a 64Kb di contenuti? Perchè un entente mi sembra abbia ipotizzato una cosa differente.

Un settore occupa 512 Bytes, un cluster di 64KB occupera' 128 settori contigui.

[BlueKnight]

Grazie mille, stando al tuo metodo dovrei avere dei cluster da 12k, per cui potrei scegliere o 8K o 16K.

Grazie mille per l'aiuto e le informazioni

[Gli_Altri_Mondi]

Gentile repne scasb, mi è piaciuto molto quello che hai scritto.

Lo cercavo da anni e mi piacerebbe non lasciar affondare questa discussione.

Per ora chiedo se quel /32 della formula è legato al FAT32 e, più in generale, se vi sono alcune differenze circa quanto hai scritto per il FAT16 e l'NTFS.

Grazie,

[rеpne scasb]

■

[Gli_Altri_Mondi]

Ciao e grazie per la spiegazione.

Negli ultimi anni ho avuto uno spazio perso, in media, del 10-15% (o più), almeno in partizioni con files piccoli, tipo SO. Con cluster di 32 o anche 64 KB.

Questo per la storia delle prestazioni (letture sbrigative di scritture sbrigative su internet). In realtà, "a pelle" non mi ha mai convinto e poi ci sono tanti fattori che influenzano il risultato, anche meccanici.

Anche la storia delle partizioni piccole... sì... ma anche lì non è così lineare (e neppure logaritmico!).

Oggi sono stato poco bene, quindi ho passato la giornata in camera a fare una prova molto semplice, che però potrebbe dire qualcosa anche più ecologicamente di un benchmark.

Ho misurato i tempi di copia di un file di 700 MB e di una cartella di 500 MB circa con tanti files vari, anche molto piccoli (il cd di installazione di Xp).

Questo in vari FS (FAT16, FAT32 e NTFS).

Poi magari posterò la lunga lista di misurazioni, ma posso anticipare che il FAT16 non è mai più veloce del FAT32 (non sono sceso sotto il giga e mezzo di partizione), posso anticipare che il file da 700 MB sembrava indifferente alle variazioni di grandezza di cluster (da 1 a 64), peggiorando di un secondo con 1 KB di cluster. I files di Xp, invece, hanno mostrato che, in FAT32, il cluster più ottimizzante è quello grande 8 KB, anche se 2 e 4 danno risultati peggiori solo di qualche decimo. Vanno un po' peggio 1 e 16 e, 32 e 64, aumentavano i tempi di copia anche del 10-20%!

NTFS leggermente più lenta della FAT32, ma solo di 1-2 secondi (su un minuto e poco più)... fino a 20 GB è comunque più veloce la prima (dopo non ho testato).

La grandezza della partizione non ha quasi effetto (da 2 a 20 GB circa), perdendo in media mezzo secondo a parità di cluster. Dopo i 16 GB, la FAT32 di default passa ai 16 KB e questo gli comporta uno scalino negativo di 2-3 secondi. Rimanere negli 8 KB è fattibile, ma si inizia a presentare lo stesso inconveniente di FAT32 sopra i 32 GB con cluster da 32 KB: la tabella di allocazione si allunga e non giova alla performance.

Risultati ideali tra gli 8 e i 10-11 GB con cluster 8 KB, come tra i 2 e i 4 GB, curiosamente non con cluster da 4 KB, ma sempre da 8 (si parla di 30-40 centesimi di sec su un minuto, comunque).


Per ora è tutto. Mi ha colpito soprattutto che il vantaggio dei files grandi con cluster grandi riesce appena a compensare con la maggiore rotazione richiesta al disco, dunque il miglioramento si annulla. Quindi passerò dai 64 agli 8 KB anche per le partizioni video... almeno fino a quando ci saranno supporti elettromeccanici!