Newsgroup: it.comp.os.dibattiti
Titolo: LFS

non mi sono mai addentrato troppo nel problema, ma qualcuno mi spiega
perche' ogni tanto si dice che il filesystem di linux non necessita di
deframmentazione?
e' cosi' ottimizzato?


$ cd /pub
$ more beer

Scusa, ma ``LFS'' sta per te ``Linux File System''?
Se si, su linux di fs ne hai uno sproposito. Quello di default, cioè 
quello che intendi tu, è ``ext2'' o l'attuale versione ``ext3'' che 
aggiunge journalling.



No, sono i FS che necessitano deframmentazione
che sono stati fatti con i piedi, anche per
motivi storici, a dire il vero.
Comunque una idea potrebbe essere quella di
salvare i dati scegliendo i blocchi sul disco
in modo opportuno, cioe` invece di prendere
il primo blocco libero, senza considerare
quanto affolata sia quell'area, si potrebbe
scegliere uno spazio piu` libero, che magari
consenta di salvare piu` blocchi consecutivamente.
Considerando che esiste il disk cache in
scrittura, e` facile avere un insieme di
blocchi consistente, da salvare in modo
contiguo sul disco.
Questo e` solo un esempio, vi sono altre cosette
che potrebbe aiutare.
Certo e` possibile frammetare anche un FS come
ext2, per esempio creando 200 file da 3MB,
aggiungendo poi 100 byte alla fine di ogni file,
cancellando il 20% dei file, ricreando i file
mancanti, ma con una dimensione piu` grande, etc.
bye,
-- 
   Piergiorgio Sartor

 mancanti, ma con una dimensione piu` grande, etc.
Maniacale! :) Qualcuno l'ha mai provato?


 Maniacale! :) Qualcuno l'ha mai provato?
Si, certamente, sono arrivato al 60% di
frammentazione, riportato da e2fsck.
Fortunatamente i file cosi` manipolati sono
finiti su CD, la dir e` stata ripulita e
tutto e` tornato normale.
Tra l'altro un semplice "mv daqui ali;
mv ali daqui" deframmenta tutto, avendo
lo spazio disponibile, ovviamente
bye,
-- 
   Piergiorgio Sartor

 lo spazio disponibile, ovviamente
Della serie: ``lascioilpcaccesolanotteamacinare'' :)


 ha scritto nel messaggio
news:b73nkm$d7o$1...@fata.cs.interbusiness.it...

si'

 frammentazione, riportato da e2fsck.
e2fsck riporta la percentuale di inode (file) i cui blocchi non sono
contigui.  Non e' una misura della frammentazione, la metrica usata
trae un po' in inganno :)
Nel tuo caso il 40% dei file sono perfettamente allocati, il
restante 60% puo' essere rotto anche solamente in due pezzi
e cio' dal punto di vista delle prestazioni e' trascurabile.
C'e da dire anche che in ext2/3 file molto grandi non potranno mai
essere allocati perfettamente se superano un certa soglia all'interno
del loro block group, proprio per evitare di trovarsi in situazioni
spiacevoli dopo.
Se vuoi vedere il layout di un file su disco usa bmap.c, di akpm:
http://www.zip.com.au/~akpm/linux/patches/stuff/
In ogni caso, piu' che la frammentazione dei file vera e propria conta
la localizzazione dei file sotto la stessa directory, cioe' il fatto
che siano tutti allocati vicini.
-- 
Lorenzo

 che siano tutti allocati vicini.
Piu` che altro dipendentemente dalla dimensione.
Mi pare di ricordare che file piccoli e` meglio
che stiano vicino alla dir, file grandi, invece,
possono stare anche lontano.
bye,
-- 
piergiorgio

Piergiorgio Sartor wrote:

Proprio cosi'.
-- 
Lorenzo

 wrote in message
news:2bila.25842$
iy5.7...@twister2.libero.it

POBOBOYYYYYYYYY. Stanno parlando bene di ext2, DOVE SEI?
C:\>iao Angelo
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 POBOBOYYYYYYYYY. Stanno parlando bene di ext2, DOVE SEI?
 
Credo stia cercando i 28 pannelli di controllo di Gnome :->
Certo che i personaggi clue del gruppo mi mancano un bel po'...
Ciao,
	Nicholas