[Linux-Biella] Frammentazione file

Mer 11 Maggio 2011 16:50:45 CEST


Il 11/05/2011 16:31, Daniele Segato ha scritto:
> 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
I disci attuali, quelli economi/comuni per intenderci, sono generalmente 
composti da un solo piatto ed usa una o due superfici. Tutti i dischi di 
spessore inferiore allo standard da 3.5" sono composti da un solo piatto.
> 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".
Nei dischi moderni il remap viene già fatto dal costruttore, in quanto 
la densità è tale che gli errori sono comuni. Infatti i disci ad alte 
prestazioni hanno capacità decisamente inferiori.
> 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.
I controller AHCI, sui dischi che lo supportano, abilitano un sistema di 
disposizione dati intelligente, il sistema è gestito dal driver e non è 
sotto il controllo del SO (che sia windows o linux).
> 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 fai 8mb di cache e salta la corrente i danni sono enormi... Non mi 
pare una bella furbate se linux lo fa a priori. In windows è 
abilitalitabile la cache write back, in ogni caso non userà mai 8Gb in 
quanto inutile e penalizzante in fatto di prestazioni (se richiedo 4gb, 
hai idea di quanto ci metterebbe a scaricare la cache?).
> 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
>
Lo fa il driver AHCI.
> è 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.
Certo infatti il defrag di windows, non deframmenta il 100% e ci sono 
altri defrag che fanno il lavoro ottimizzato per uso desktop, il defrag 
di windows funziona in modo medio, un po' per ogni uso.
> 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
>
Si ma resta il fatto che non è windows merda e linux figo... Vorrei 
vedere come si comporta un pc con linux con emule una tonnellata di film 
e mp3 so programmi e ogni cosa tutto nello stesso disco, possibilmente 
abbastanza pieno. Solitamente è il caso in cui windows inizia ad andare 
in crisi (infatti è consigliato di non scendere sotto il 10% di spazio 
libero). Se parliamo di 50% di spazio libero, windows non ha nessun 
problema (da vista in poi, in xp il defrag di default non è attivo, ma 
ci vuole poco ad abilitarlo).

JJ