Newsgroup: it.comp.os.linux.iniziare
Titolo: Miti e leggende sulla frammentazione del file system [WAS Re: programmi indispensabili]

 Mi sembra di ricordare che l'fsck schedulato aiutasse in tal senso
Fsck non deframmenta, da quel punto di vista si limita soltanto ad 
analizzare il livello di frammentazione del disco. A questo punto, direi che 
sia ora di sfatare il mito del "Linux non ha bisogno della 
deframmentazione". Linux ha bisogno della deframmentazione, ma solo in certi 
contesti. Supponiamo che quello rappresentato qui sotto sia un disco rigido 
formattato in FAT (in NTFS dovrebbe essere identico, ma non ne sono sicuro) 
dove ogni settore rappresenta un byte:
-----------------------
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
-----------------------
Nel momento di scrivere i dati del file A, avremo questa situazione:
-----------------------
|A|A|A|A| | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
-----------------------
Ora, supponiamo di aggiungere il file B:
-----------------------
|A|A|A|A|B|B|B|B|B|B|B|
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
-----------------------
E, successivamente, di modificare il file A:
-----------------------
|A|A|A|A|B|B|B|B|B|B|B|
|A|A|A| | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
-----------------------
La situazione penso che sia chiara: abbiamo il file A frammentato in quanto 
i suoi dati sono sparsi per il disco a causa di una occupazione del file 
system da parte di altri dati. Cosa succede su Linux? Partiamo dalla 
scrittura del file A:
-----------------------
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | |A|A|A|A| | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
-----------------------
In sostanza, non e` detto che la scrittura del file sia sequenziale, anzi, 
aggiungendo il file B nulla ci vieta di avere questa situazione:
-----------------------
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | |B|B|B|B|B|B|
|B| | | | | | | | | | |
| | |A|A|A|A| | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
-----------------------
Ovvero, l'allocazione non e` per nulla contigua rispetto allo spazio 
occupato disponibile. Questo perche` in Linux e` implementato un algoritmo 
di rilocazione dei file in modo da evitare partendo *dalla* *radice* 
problematiche di frammentazione. Questo e` ottimo, ma solo in determinate 
circostanze, ovvero, non e` infrequente di ritrovarsi in situazioni del 
genere:
-----------------------
| | |C|C| | | | | | | |
| | | | | | | | | | | |
| | | | | |B|B|B|B|B|B|
|B|B|B|B|B|B|B|B|B|B|B|
|B|B|A|A|A|A|A|B|B|A|A|
|A| | | | |E|E|E|E| | |
| |F|F|F| | | | | | | |
| | | | | | |D|D|D|D|D|
-----------------------
In altre parole, la crescita del file B (che potrebbe essere benissimo un 
log) e` stata tale da provocare sia la sua frammentazione che la 
frammentazione di altri file. E a questo non c'e` file system che tenga, 
l'unica e` deframmentare, e gli unici modi per farlo sono tramite gli 
appositi tool (se esistono) o ricreando il file. Su Windows, tali tool sono 
disponibili in una infinita` di modi (da quelli che usano il motore interno, 
come MyDefrag, a quelli che ne implementano uno proprio), sotto Linux o non 
sono disponibili (e.g. per ext3 non esistono, mentre per ext2 esiste e per 
ext4 e` pianificato), o sono disponibili solo per determinati file system 
(e.g. per XFS c'e` xfs_fsr). Questo, ovviamente, non significa che una delle 
due situazioni sia meglio dell'altra, ma semplicemente che ogni sistema si 
approccia in modo differente al problema (in Windows ci si affida totalmente 
al defrag, in Linux si cerca prima di evitare il problema e poi, se proprio 
non si puo` evitare, ti allerta)
Enrico
P.S. e` impostato l'xpost con it.comp.os.linux.iniziare
P.S. giusto per completezza, su Linux esiste filefrag che mostra lo stato di 
frammentazione di un file
P.P.S. per chi sia interessato al discorso, puo` partire da qui: 
http://en.wikipedia.org/wiki/Defragmentation
 (tra le altre cose vi e` un 
link ad uno schema piu` dettagliato di quello che ho fatto io)

 P.S. IMHO una frammentazione del 5/10% è come se non esistesse.
Dipende dai punti di vista, se hai un disco di 2TiB, una frammentazione del 
10% equivale a 2GiB di dati non contigui
Enrico

 Enrico
se hai un disco di 2TiB _pieno_ la frammentazione e' il tuo problema 
minore
-- 
.,¸¸,ø¤º°°º¤ø,¸_¸cRuncH.,¸¸,ø¤º°°º¤ø,¸_¸
           and....yes, we crunch
 
"This generation may be the one that will face Armageddon."
		-- Ronald Reagan, "People" magazine, December 26, 1985

 10% equivale a 2GiB di dati non contigui
No dovrebbero essere 200 Gib il 10%?
Giulia

 No dovrebbero essere 200 Gib il 10%?
Doh! e` vero :D
Enrico

 minore
Non e` detto che per avere il 10% di frammentazione il disco debba essere 
pieno. Una frammentazione alta puo` essere dovuta a molti fattori, non 
sempre dovuti alla saturazione dello spazio (e.g. un alto I/O sul disco puo` 
dare origine ad un alto livello di frammentazione)
Enrico

 -----------------------
Il file di log più grosso sul mio pc è 2,4M:
# filefrag -v /var/log/openvpn.log 
Filesystem type is: ef53
File size of /var/log/openvpn.log is 2423920 (592 blocks, blocksize 4096)
 ext logical physical expected length flags
   0       0  2414585               1 
   1       1  3070481  2414585      1 
   2       2  3070483  3070481      1 
   3       3  3070498  3070483      1 
   4       4  3070501  3070498      1 
   5       5  3070503  3070501      1 
   6       6  3070505  3070503      1 
   7       7  3070507  3070505      1 
   8       8  3070510  3070507      1 
   9       9  3070512  3070510      1 
  10      10  3070516  3070512      1 
  11      11  3070530  3070516      4 
  12      15  3049020  3070533     17 
  13      32  3053696  3049036     32 
  14      64  3053568  3053727     64 
  15     128  3059456  3053631    128 
  16     256  3468032  3059583    256 
  17     512  3565056  3468287     73 
  18     585  3539071  3565128      1 
  19     586  2991951  3539071      1 
  20     587  5798225  2991951      1 
  21     588  6522950  5798225      4 eof
/var/log/openvpn.log: 22 extents found
Frammentazione notevole per soli 2,4M.
Nicola.
P.S. complimenti per il tempo perso a fare i disegnini.
P.S.2 avevo postato su it.comp.os.windows.xp (manco lo seguo questo)
chi va pian va san e va lontan

 Enrico
10% è 10% che sia di 1Mb o di miliardi di TB, per un 10% non ha senso andare 
a cercarsi guai nel resto del filesystem, è molto più saggio semplicemente 
prendere un disco del 10% più grande.
E in ogni caso se hai riempito il 90% dello spazio, in un decimo del tempo 
(a essere molto ottimisti) finirai lo spazio anche del 10% teoricamente 
recuperabile.
E il tempo perso e il rischio corso per deframmentare un 10% è 
sproporzionato al risultato ottenuto, risultato che poi viene rapidamente 
perso.
In sintesi, concordo con l'idea che se hai riempito il disco, una 
frammentazione del 10% non è il problema ne la soluzione.



Se non sbaglio lo stesso defrag di win si rifiutava di partire sotto la 
soglia del 20% di frammentazione, e parliamo di FAT su dischi che erano 
quelli di 15 anni fa....
Resta IMHO corretta l'analisi che hai fatto sul diverso approccio di 
ciascun filesystem nei confronti della potenziale frammentazione, a cio' 
aggiungo che potendo mettere le mani ai sorgenti.....
http://tinyurl.com/5vvybp4
--
.,¸¸,ø¤º°°º¤ø,¸_¸cRuncH.,¸¸,ø¤º°°º¤ø,¸_¸
           and....yes, we crunch
 
Never argue with a fool -- people might not be able to tell the 
difference.

 del 10% equivale a 2GiB di dati non contigui
Una domanda: Come si misura la frammentazione?
Sembra strano ma non sono riuscito a trovare una risposta; i testi sacri 
tacciono, San Google fa orecchie da mercante, Wikipedia è reticente, la 
sfera di cristallo sta dal lustra-sfere-di-cristallo.
Cosa vuol dire "Un disco è frammentato al 10%"? Che il 10% dei dati non è 
contiguo? Potrebbe essere, i conti che fai sarebbero giusti, ma questa 
misura è una misura valida per la frammentazione? Potrebbe andare per la
frammentazione della memoria RAM ma per la memoria sul disco va bene?
Io penso di no. Pensa ad una situazione limite, un disco con migliaia di 
file piccoli e medi contigui e di pochi grossi file frammentati che però
ammontano al 10% dello spazio; la frammentazione non sarebbe un 
problema ma comunque avresti una frammentazione del 10%.
L'alta possibilità è ovvia: Un disco è frammentato al 10% perché il 10%
del file è diviso in più frammenti. Calcolo ovvio, il dieci per cento dei 
file è frammentato. Quindi la dimensione /media/ di un file moltiplicato per
 il numero dei file frammentati dà un risultato /medio/ di 200GiBi 
È così? Ma manco per sogno! È più facile che un file grosso sia frammentato 
quindi devi fare la media /statistica/ e non la media /semplice/ e quindi il 
risultato potrebbe essere molto diverso dai 2GiBi o dai 200GiBi
Ma il problema vero è come misurare la frammentazione: questa neanche 
mi sembra una misura valida: accedere ad un file di piccole dimensioni
diviso in due frammenti non è come accedere ad un file di grosse dimensioni
diviso in due frammenti; nel secondo caso la frammentazione non è un grosso 
problema. Mancano perfino le basi per ragionare in termini coerenti sul 
problema.
IMHO non vale la pena discutere tanto sui ma applicare il buon senso al caso 
particolare in esame e considerare che serve deframmentare solo in casi 
particolari e che il metodo più economico e sicuro per deframmentare è 
ripristinare da un backup di livello 0. 

 frammentazione del 10% non è il problema ne la soluzione.
Se hai riempito un disco, e` lapalissiano che vi sono altri problemi a cui 
una deframmentazione non riesce a porre rimedio, ma in quel caso e` corretto 
agire in altri modi (cambiare disco in primis)
Enrico

 
]zac[
... secondo me non ha senso non calare la teoria sulla realtà, ma 
probabilmente è insensato anche questo ...