| Miti e leggende sulla frammentazione del file system [WAS Re: programmi indispensabili] [messaggio #36543] |
sab, 12 marzo 2011 15:47  |
 Enrico 'Henryx' Bianc
Messaggi: 212
Registrato: febbraio 2011 |
Senior Member |
|
|
Francesco wrote:
> 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)
|
|
|
| Re: Miti e leggende sulla frammentazione del file system [WAS Re: programmi indispensabili] [messaggio #36594 è una risposta a message #36543] |
dom, 13 marzo 2011 14:35  |
NicoKid
Messaggi: 212
Registrato: novembre 2010 |
Senior Member |
|
|
Enrico 'Henryx' Bianchi wrote:
> 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|
> -----------------------
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
|
|
|
My forum, my way! Il forum dei newsgroup
Utenti
F.A.Q.
Registrati
Login
Home
E-mail ad un amico 
