[Linux-Biella] Frammentazione file

[PaulTT]

On 11/05/2011 17:21, ledi salillari ?:
>
>
> Il giorno 11 maggio 2011 16:50, Jumping Jack <jumpingjack a mclink.it 
> <mailto: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
>         <mailto: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.
ies
tra l'altro, i sistemi 'veri' la cache non la ripuliscono manco delle volte
(come l'iseries ad esempio ;P, se si pianta davvero tutto, puoi ancora 
recuperarla, e farla riscrivere dopo)

-- 
Non che non sia possibile rompere un server di posta su una piattaforma
diversa, ma exchange arriva già rotto. E' un enorme risparmio di tempo.

-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://ml.bilug.linux.it/pipermail/linux/attachments/20110512/ee6cca35/attachment.htm>