[Linux-Biella] Frammentazione file

[ledi salillari]

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

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.



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



> 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/ed5b1997/attachment-0001.htm>