Loading
Home » Computer » Linux » Re: Miti e leggende sulla frammentazione del file system [WAS Re: programmi indispensabili]
Re: Miti e leggende sulla frammentazione del file system [WAS Re: programmi indispensabili] [messaggio #36570] |
dom, 13 marzo 2011 02:16 ![Messaggio successivo Messaggio successivo](theme/adv/images/down.png) |
Enrico 'Henryx' Bianc Messaggi: 212 Registrato: febbraio 2011 |
Senior Member |
|
|
Ripristino l'xpost, in quanto avevo dimenticato di togliere il followup (mi
scuso per il disagio)
Giuseppe Della Bianca wrote:
> Non è un mito, basta precisare i termini.
Probabile, ma il problema e` che viene visto proprio in quella maniera. Per
capirci, il mio rant e` partito proprio dall'ennesimo sfottimento a causa
del mancato uso dei tool di deframmentazione su Linux, quando nella realta`
dei fatti ci sono o sono previsti ma, soprattutto, in alcuni contesti sono
decisamente utilizzati
> I filesystem linux/unix (non tutti) normalmente e molto spesso non hanno
> bisogno di essere deframmentati, perché il loro modo di essere gestiti
> permette di mantenere la frammentazioni a valori più che buoni.
Vero, pero` tieni presente che si e` preferito gestire la casistica generica
(i file non contigui sono frammentati), ed ignorare un paio di casistiche
limite ma frequenti ("lo spazio non contiguo e` spazio frammentato" e "piu`
il disco e` pieno, piu` si rischia la frammentazione"). Ed e` proprio per
gestire anche queste casistiche che esistono i tool di deframmentazione
> Poi la frammentazione vera e propria è diversa dallo spreco di spazio
> durante l'allocazione di file di piccole dimensioni.
In teoria sono tutti e due dei livelli di frammentazione, solo che si
distinguono sia per come si comportano (lo slack space o frammentazione
interna frammenta lo spazio in quanto ne rende parte inutilizzabile, la
frammentazione esterna o dei dati suddivide in piu` blocchi non contigui i
dati registrati in un file), sia per le metodologie di correzione, (la
frammentazione interna la si elimina tramite block suballocation o tail
packing, attualmente implementata su Btrfs, ReiserFS e, in parte, ZFS)
> Miti per giunta pericolosi.
Appunto
> 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
|
|
|
Re: Miti e leggende sulla frammentazione del file system [WAS Re: programmi indispensabili] [messaggio #36576 è una risposta a message #36570] |
dom, 13 marzo 2011 10:26 ![Messaggio precedente Messaggio precedente](theme/adv/images/up.png) ![Messaggio successivo Messaggio successivo](theme/adv/images/down.png) |
crunch Messaggi: 48 Registrato: novembre 2010 |
Member |
|
|
Il Sun, 13 Mar 2011 02:16:42 +0100, Enrico 'Henryx' Bianchi ha scritto:
>> 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
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
|
|
| | | |
Re: Miti e leggende sulla frammentazione del file system [WAS Re: programmi indispensabili] [messaggio #36599 è una risposta a message #36570] |
dom, 13 marzo 2011 16:11 ![Messaggio precedente Messaggio precedente](theme/adv/images/up.png) ![Messaggio successivo Messaggio successivo](theme/adv/images/down.png) |
Giuseppe Della Bianca Messaggi: 1545 Registrato: dicembre 2010 |
Senior Member |
|
|
Enrico 'Henryx' Bianchi wrote:
Ribadisco solo che la frammentazione è solo un punto, meno importante di
tanti altri, di un filesystem
]zac[
>
>> 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
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.
|
|
|
Re: Miti e leggende sulla frammentazione del file system [WAS Re: programmi indispensabili] [messaggio #36606 è una risposta a message #36591] |
dom, 13 marzo 2011 19:55 ![Messaggio precedente Messaggio precedente](theme/adv/images/up.png) ![Messaggio successivo Messaggio successivo](theme/adv/images/down.png) |
crunch Messaggi: 48 Registrato: novembre 2010 |
Member |
|
|
Il Sun, 13 Mar 2011 14:24:22 +0100, Enrico 'Henryx' Bianchi ha scritto:
> crunch wrote:
>
>> se hai un disco di 2TiB pieno la frammentazione e' il tuo problema
>> 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)
>
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.
|
|
|
Re: Miti e leggende sulla frammentazione del file system [WAS Re: programmi indispensabili] [messaggio #36612 è una risposta a message #36590] |
lun, 14 marzo 2011 00:38 ![Messaggio precedente Messaggio precedente](theme/adv/images/up.png) ![Messaggio successivo Messaggio successivo](theme/adv/images/down.png) |
mallin.shetland Messaggi: 129 Registrato: novembre 2010 |
Senior Member |
|
|
Addì domenica 13 marzo 2011 14:16 Enrico 'Henryx' Bianchi scrisse:
> Giulia wrote:
>
>> No dovrebbero essere 200 Gib il 10%?
>
> Doh! e` vero :D
Non mi tornano i conti. Partiamo dall'inizio:
Addì domenica 13 marzo 2011 02:16 Enrico 'Henryx' Bianchi scrisse:
> Dipende dai punti di vista, se hai un disco di 2TiB, una frammentazione
> 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.
|
|
|
Re: Miti e leggende sulla frammentazione del file system [WAS Re: programmi indispensabili] [messaggio #36639 è una risposta a message #36599] |
mar, 15 marzo 2011 00:27 ![Messaggio precedente Messaggio precedente](theme/adv/images/up.png) ![Messaggio successivo Messaggio successivo](theme/adv/images/down.png) |
Enrico 'Henryx' Bianc Messaggi: 212 Registrato: febbraio 2011 |
Senior Member |
|
|
Giuseppe Della Bianca wrote:
> 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.
Questo, francamente, non ha senso, e` come se per raccogliere della sabbia
prendo un tavolino piu` 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.
Direi che in questo passaggio ci sia parecchia confusione, io non
deframmento per recuperare spazio, ma per recuperare performance. Avere un
file scritto sequenzialmente significa leggerlo completamente con un solo
passaggio della testina su disco. Avere un file frammentato su piu` settori
non contigui significa aspettare piu` cicli disco per leggerlo tutto (e,
vorrei ricordarlo, i maggiori tempi di latenza sono proprio dati dalla
velocita` di accesso ai dati su disco). Stesso discorso per lo spazio non
contiguo. In alcuni casi queste situazioni sono inaccettabili, sia se si
tratta del 10% dei dati complessivi scritti su disco, sia se si tratta del
10% della dimensione del disco stesso (porto tutti e due gli esempi visto
che in un altro post e` stato fatto notare che questo particolare non e`
chiaro)
> E il tempo perso e il rischio corso per deframmentare un 10% è
> sproporzionato al risultato ottenuto, risultato che poi viene rapidamente
> perso.
Se ho un grosso I/O con cancellazione e aggiunta dati potrebbe essere cosi`,
ma mi viene in mente un mail server a cui l'utente vi accede via IMAP: i
dati, una volta deframmentati, difficilmente vengono modificati
> In sintesi, concordo con l'idea che se hai riempito il disco, una
> 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
|
|
|
Re: Miti e leggende sulla frammentazione del file system [WAS Re: programmi indispensabili] [messaggio #36752 è una risposta a message #36639] |
dom, 20 marzo 2011 14:21 ![Messaggio precedente Messaggio precedente](theme/adv/images/up.png) |
Giuseppe Della Bianca Messaggi: 1545 Registrato: dicembre 2010 |
Senior Member |
|
|
Enrico 'Henryx' Bianchi wrote:
> Giuseppe Della Bianca wrote:
>
>> 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.
>
> Questo, francamente, non ha senso, e` come se per raccogliere della sabbia
> prendo un tavolino piu` grande
>
]zac[
.... secondo me non ha senso non calare la teoria sulla realtà, ma
probabilmente è insensato anche questo ...
|
|
|
Vai al forum:
Ora corrente: lun set 02 01:30:03 CEST 2024
Tempo totale richiesto per generare la pagina: 0.02371 secondi
|