[Linux-Biella] Frammentazione file

[Daniele Segato]

2011/5/11 Jumping Jack <jumpingjack a mclink.it>:
> Non so se sia possibile ora fare quello che hai scritto. La struttura del
> disco interno non è accessibile al SO, infatti il disco può rimappare
> settori a suo piacimento, quando li trova danneggiati o prossimi al
> danneggiamento. Per cui uno spazio continuo logicamente può non essere
> contiguo fisicamente. E' però possibile che la logica di struttura di ext
> sia, in fase di creazione, compatibile con il tipo di disco. In ogni caso la
> maggior parte dei dischi ora è composta da un solo piatto e spesso ne viene
> usata una sola faccia, per cui, l'adiacenza spaziale è limitata a 5 e
> nemmeno sempre. Ci possono anche essere intere tracce saltate e
> l'allineamento tra tracce adiacenti non è logico, ma è relativo al tempo di
> spostamento della testina, per cui dubito che ci sia corrispondenza tra
> piatti diversi.


un disco fisso magnetico è formato da un insieme di dischetti uno sopra l'altro
la testina si infila tra un disco e l'altro leggendo sopra e sotto ad ogni disco
il disco ruota e la testina può scorrere avanti e indietro

guardate almeno le figure prima di proseguire se non sapete com'è
fatto un disco:

http://en.wikipedia.org/wiki/Cylinder-head-sector
http://en.wikipedia.org/wiki/Disk_sector
http://en.wikipedia.org/wiki/File:Disk-structure2.svg

un blocco o cluster del disco è un insieme di settori.

il sistema operativo sa quanto è grande un blocco e anche se qualche
settore può essere rimappato questo in genere non avviene su tutti i
settori ma su pochi "sfigati".

questo non inficia il funzionamento...

il disco è veloce a girare, il limite non è nel passare da un settore
all'altro della stessa traccia ma nel cambiare traccia.

la testina [meglio, le testine] (heads) sono lente a cambiare
direzione (lento è un concetto relativo...)
quindi se i dati sono tutti vicini e soprattutto non devo continuare a
fare avanti e indietro con le testine.

un disco da 5400 rpm è più lento a girare di un 7600 rpm (round per
minute, giri al minuto)

se il file si trova in tracce contigue arriverò al massimo della
velocità leggendolo

il seek time è quanto ci mette la testina ad arrivare in qualunque
punto del disco, in genere qualche millisecondo.

se vado a leggere tanti piccoli file in punti sparpagliati nel disco e
in ordine "stupido" la testina dovrà saltare da una parte all'altra
è uno dei motivi per cui ci va più tempo a trasferire tanti piccoli
file che un grosso file.

Linux poi fa cache in ram del disco riempiendo totalmente la ram (se
hai 8 gb di ram li avrai pieni, Linux li usa tutti visto che l'hai
pagata).
non so windows, anni fa non lo faceva.

Se il sistema richiede 5 dati diversi che si trovano in 5 tracce
diverse del disco è stupido andare alla traccia 60 poi indietro alla
20 poi di nuovo alla 70 quindi alla 30 ed infine alla 75

molto più furbo leggere in ordine la 20 poi la 30 poi la 60, la 70 e la 75

è molto più complesso di quanto può sembrare...

il problema della frammentazione non tocca i filesystem Linux perché
organizzano bene i dati e la frammentazione non supera mai (misura
empirica) il 3-4 % (se non sbaglio)...

NOTA BENE: quando windows ti dice frammentazione 0% perché ha messo
tutti i file in fila, questo non significa che sia più veloce... se a
te serve un file alla traccia 20 e poi uno alla 70 che siano tutti in
fila o meno ti frega poco, la testina si deve comunque fare un bel po
di salti qua e là per darti tutto quel che ti serve.

ordinare i dati in modo intelligente non è solo questione di metterli
in fila senza spazi tra loro :)

spero di aver fornito una vaga idea e sono ben venute correzioni o precisazioni

http://en.wikipedia.org/wiki/Block_(data_storage)