[Linux-Biella] Frammentazione file

[ledi salillari]

Il giorno 11 maggio 2011 16:50, Jumping Jack <jumpingjack a mclink.it> ha
scritto:

>
>
> 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.
>>>
>>
l'unica cosa che può fare un hard disk è di posizionare le testine e
leggere/scrivere sulla traccia sottostante ad esse. ovviamente alla massima
velocità possibile e con la massima precisione possibile. TUTTO il resto
viene fatto dal sistema operativo e/o da qualche driver se ce ne sono.


>
>> 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.
>
> i dischi da 3.5 hanno almeno 2 piatti (4 superfici). quelli superiori ai
500gb hanno molto probabilmente da 3 in su.
i dischi da 2.5 hanno 1 piatto fino a 120gb. attualmente ne stanno facendo
anche da 250 su un singolo piatto. generalmente ne hanno 2. il mio da 500g
ne ha 2.

>  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.


il remap viene fatto da sistemi di calcolo di somme per correggere
automaticamente gli errori se presenti. per gli amici si chiama CRC. può
essere implementato sia a livello hardware che software. linux lo fa. se è
presente anche sul disco è una protezione in +.


>
>  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).


vale anche qui il commento di prima. se il sistema operativo implementa già
una disposizione ottimale dei dati, tale driver diventa pressoché inutile.
altrimenti è necessario, ma come dici tu stesso: solo se il disco lo
supporta ;)


>
>  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?).


non hai idea di come funzioni la cache a livello hardware vero? per cache si
intende una memoria temporanea, che viene versata su un supporto veloce per
andare a finire sul supporto lento in seguito. i dati NON stanno nella
cache. se devi caricare (dall'hd) un blocco di dati non presente in ram,
viene caricato insieme a tutti i blocchi adiacenti (e questi insieme ai loro
blocchi adiacenti ecc) fino a occupare la ram. così, se ti servono dei dati,
per delle statistiche che non sto a scrivere qui, è molto probabile che tali
dati siano quelli adiacenti che hai caricato prima. quindi, se hai tanta
cache, le prestazioni *non possono fare altro che aumentare*.
ovviamente questo richiede una sincronizzazione per i dati modificati,
ovvero vengono modificati il prima possibile anche sul supporto lento. non
c'è bisogno di scaricare tutta la cache. ogni volta che ce n'è bisogno
vengono aggiornati i dati modificati. se salta la corrente perdi una
quantità molto piccola di dati (ovvero quelli non ancora sincronizzati). non
è assolutamente vero che perdi 8gb di dati. facendo una cifra, su 1gb di
cache perdi si o no qualche kilo. questo perché i dati sono costantemente
aggiornati.

in altre parole, la cache è una estensione logica di un supporto lento su
uno veloce. i dati sono gli stessi, solo che ci accedi più velocemente.


>
>  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.


il problema è che tale defrag viene fatto solo quando l'utente si ricorda di
farlo. quindi non è una soluzione efficace.


>
>  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).
>

stiamo parlando di implementazioni strutturali. secondo test empirici e
matematici, la gestione dei dati presenti sull'hd su windows è poco
efficiente rispetto ad altri sistemi. e questo non lo puoi negare.
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://ml.bilug.linux.it/pipermail/linux/attachments/20110511/4453586c/attachment-0001.htm>