[Linux-Biella] Frammentazione file

[Jumping Jack]

On 11/05/2011 18:16, ledi salillari wrote:
> ho scritto un messaggio simile a quello di daniele ma a quanto pare 
> non è arrivato a destinazione perché troppo lungo.
>
> comunque jj stai sparando una marea di stronzate.
>
>         dammi un link che dimostri che esistono disco ad 1 solo piatto che
>         siano dei normali 3.5 pollici o 2.5 pollici
>
>     Non trovo niente, non è neanche più specificato. Ma hai provato a
>     guardare quando è spesso un hdd recente? Forse quelli da 2T hanno
>     più di un piatto.
>
>
> i dischi da 3.5 hanno almeno 2 piatti. quelli superiori ai 500gb anche 
> di +.
> 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 (2.5") ne ha 2.
I dischi da 3.5 hanno al massimo 2 piatti e possono utilizzare 2, 3 o 4 
testine. I dischi ad alte prestazioni potrebbero essere fatti diversamente.
>
>             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).
>
>
> se il sistema operativo implementa già una disposizione ottimale dei 
> dati, tale driver diventa pressoché inutile. altrimenti è necessario 
> ma come tu stesso dici, è supportato solo da alcuni dischi.
Ogni disco prodotto da 5 anni a questa parte supporta lo NCQ.
>
>         forse non mi son spiegato
>         è cache in lettura quella che riempie la ram
>
>         la cache in scrittura è comunque gestita con il journaling del
>         filesystem che dovrebbe avere anche NTFS
>         quindi la perdita di dati è minima
>
>     Ma la cache in lettura chi se ne fraga, che i dati siano letti
>     lentamente o velocemente se sono i cache non cambia nulla.
>
>
> cambia eccome!!
> non sai come funziona la cache vero? immagina un raid 1 tra hard disk 
> e ram. se devo scrivere, scrivo su entrambi. quindi i tempi di 
> scrittura sono uguali a quelli del supporto + lento (hd). quindi non 
> ho ne un peggioramento ne un guadagno di prestazioni. se devo leggere, 
> leggo dalla ram. quindi tempi di accesso di circa 3 ordini di 
> grandezza più veloci. per la precisione, la lettura è più frequente di 
> quello che potresti immaginare.
Si parlava di frammentazione.
>
>     Infatti nei sistemi scsi è proprio differente il sistema e le
>     richieste devono essere inviate in modo intelligente, meglio è
>     fatto il driver migliori sono le prestazioni.
>
>
> se c'è già il sistema che lo fa in maniera ottimale non c'è bisogno di 
> driver. tranne che in soluzioni strane come il revodrive della ocz 
> (anche li non so quanto faccia il driver)
Il SO non fa distinzione tra tipologia di disco, se lo fa è perchè il 
driver è stato integrato nel SO.
>
>         fatto sta che sono necessari perché NTFS non fa un buon lavoro a
>         priori e quindi ci va qualcuno che sistemi le cose a posteriori
>
>     Questo non lo so, non sapendo come funzionano NTFS e EXT. Sarebbe
>     carino uno confronto sullo stesso FS, solo che non è possibile
>     (non sarebbe equo, in quando non pienamente supportati).
>
>
> fatto sta che il defrag su windows si fa solo quando si ricorda 
> l'utente di farlo. quindi non è una soluzione efficace.
>
>     Io non sento il bisogno di un defrag sono windows, ma se gestisco
>     la frammentazione del disco posso aumentare le prestazioni. Il
>     fatto che nessuno si preoccupi su linux, mi dice sono che tutti si
>     accontentano, senza pensare che potrebbe essere meglio.
>
> lo fa già il SO. le prestazioni sono già ottimali.
>
>         mi è capitato di arrivare a spazio 0 su disco senza rendermene
>         conto
>         fintanto che non si riempiva la /tmp (che tengo spesso in
>         partizione
>         separata) non mi ha mai ridotto le prestazioni in modo
>         percettibile.
>
>     Riempire e poi liberare non influisce neanche su windows, ma il
>     disco si riempe di file a caso lentamente, i file di log si
>     ingrossano, il jouranling aumenta, le prestazioni su windows
>     degradano.
>
> degradano anche dal fatto che la testina deve fare un miliardo di giri 
> inutili per leggere pochi bit. quindi in quel caso ci va una 
> deframmentazione. che ripeto, la deve fare l'utente.

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