[Linux-Biella] Frammentazione file

[Jumping Jack]

On 11/05/2011 11:42, PaulTT wrote:
> On 11/05/2011 03:05, Jumping Jack 說:
>>
>>
>> On 11/05/2011 2:41, ledi salillari wrote:
>>>
>>>
>>> Il giorno 10 maggio 2011 23:47, Jumping Jack <jumpingjack a mclink.it 
>>> <mailto:jumpingjack a mclink.it>> ha scritto:
>>>
>>>
>>>
>>>     On 10/05/2011 23:31, PaulTT wrote:
>>>
>>>         On 10/05/2011 22:51, Jumping Jack 說:
>>>
>>>             Come viene gestita la frammentazione dei file su Linux?
>>>             Perchè si dice che non serve deframmentare?
>>>
>>>
>>>         la frammentazione c'e'
>>>         non c'e' la frammentazione a casaccio sul disco
>>>         in sistemi diversi da windows non serve deframmentare
>>>         perche' un filesystem ben fatto (e ben supportato dal
>>>         sistema) non lascia buchi in giro dove non serve
>>>
>>>         ;P
>>>
>>>     Non ho provato, perchè non ho trovato nulla che mi visualizzi lo
>>>     stato di frammentazione del disco, ma se io salvo due file
>>>     enormi contemporanamente cosa fa? Windows frammenta in modo
>>>     smodato (se non c'è cache attiva).
>>>
>
> PS la 'cache' e' attiva di default in linux, anche per file infimi
> ;)
>
>>>     JJ
>>>
>>>
>>> allora ho fatto questa parte recentemente all'uni. ovviamente anche 
>>> su linux c'è la frammentazione in quanto è un processo inevitabile. 
>>> la differenza tra ext3-4/reiserfs/ecc e i filesystem di windows sta 
>>> nella gestione della frammentazione. in windows si cerca il primo 
>>> spazio disponibile e si infila li il dato. se non basta si 
>>> spezzetta. fine
>> E' falso, vale solo per FAT e non per NTFS.
>
> in teoria
> poi se deframmenti un ntfs vedi' che dopo varie installazioni e' molto 
> frammentato lo stesso, meno di un fat, ma piu' di altro
Intendevo che su ntfs windows non scrive nella prima posizione 
disponibile, inoltre ci sono programmi di defrag che si occupano di 
posizionare i file in scrittura, è un confronto molto difficile, 
personalmente non devo deframmentare e non ho defrag automatici in 
programma, però ho un software attivo sul posizionamento dei file. Il 
problema è che windows punta sulla comodità d'uso, più che sulle 
prestazioni, però, come linux, va "arricchito" per adeguarlo alle esigenze.
>
>>> in linux invece la gestione segue degli algoritmi più complicati, 
>>> apparentemente più lenti come azioni istantanee ma a lungo termine 
>>> sicuramente più vantaggiosi. in pratica si tiene costantemente 
>>> traccia dei movimenti e/o cancellazioni dei file e se c'è bisogno di 
>>> spazio, questo viene scelto in modo da ridurre al minimo il 
>>> movimento delle testine. non entro tanto nei dettagli ma ti faccio 
>>> un paragone semplice:
>>>
>>> su windows hai un magazzino. se questo è quasi pieno e devi metterci 
>>> degli oggetti, questi vengono posizionati nei primi buchi liberi. se 
>>> poi togli e metti per qualche volta col cazzo che ti ricordi tutte 
>>> le posizioni.
>>> in linux: il posizionamento dei bicchieri segue una logica (esempio 
>>> molto stupido, solo nelle posizioni all'altezza del gomito). quindi, 
>>> anche se tu sposti/togli/metti molti oggetti, sai già che molto 
>>> probabilmente all'altezza del gomito avrai un bicchiere. quindi la 
>>> testina dell'hd fa molta meno fatica nella ricerca, per cui una 
>>> deframmentazione è praticamente inutile.
>> Ok, ma io vorrei comunque sapere lo stato di frammentazione del mio 
>> disco. Inoltre credo che la deframmentazione sia indispensabile con 
>> il tempo, senza contare che posizione i file in modo intelligente 
>> favorisce le prestazioni. Senza defrag, deve essere il SO che si 
>> occupa del posizionamento.
>
> infatti il so si occpua del posizionamento, essendo un sistema 
> _operativo_, windows lo fa molto meno bene, e credo non sia colpa del 
> fs in se'....
> no, la deframmentazione non e' cosi' indispensabile, dato che sei 
> occupi tutto il disco, i buchi sono teoricamente davvero pochi, riduci 
> la frammentazione solo spostando tutto su un altro disco e 
> rispostandocelo dentro, a quel punto
Si certo, se è pieno si può fare ben poco.
>
>>>
>>> perché windows non usa questi sistemi? prova a chiederglielo. chiedi 
>>> anche per quale motivo su ntfs.com <http://ntfs.com> c'è scritto che 
>>> avrai quasi sicuramente dei problemi con ntfs e in quel momento 
>>> saranno solo cazzi tuoi
>> E' normale che dicano una cosa del genere, soltanto un presuntuoso 
>> può dire che non ci saranno problemi con un FS, in ogni caso se non 
>> si usa una cache NTFS è praticamente indistruttibile, e lo dico in 
>> anni di esperienza e svariate decine di computer. A differenza di FAT 
>> che invece è molto sensibile ad una mancanza di alimentazione del 
>> disco o a errori di scrittura.
>
> non so mica, io ho avuto esperienze inverse
> (sicuramente ntfs e' teoricamente meglio, e per windows stesso e' 
> sicuramente meglio, d'altro canto con l'implementazione vfat di linux, 
> sono piu' volte riuscito a recuperar piu' roba da dischi fat scassati 
> che da dischi ntfs scassati, FYI)
Scassati in che senso? Disco danneggiato o struttura logica? Uno dei 
problemi gravi che ho riscontrato negli ultimi anni è stato dato dai 
cavi sata1, dopo un po' danno dei problemi di conessione (non sempre ma 
spesso), per cui i dati arrivano al disco un po' a caso o a singhiozzo 
questo può creare problemi gravi, soprattutto se l'utente non ha 
pazienza e spegne il pc, magari decine di volte prima di chiedere aiuto.
>
>>
>>> :P
>>> bye
>>
>> Devo dedurre che non è possibile deframmentare ext4? Non c'è nulla? 
>> La mia domanda è nata perchè il mio Ubunuto inizia ad avere un 
>> attività di disco molto visibile, e non swappa.
>
> e2freefrag ti dice lo stato di frammentazion
> e2freefrag /dev/sda1
> se hai la / montata su sda1, se no cambi il numerino
> (lo scopri scrivendo mount da terminale)
Interessante, ma dice solo lo spazio libero frammentato, che è 
significativo fino ad un certo punto.


-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://ml.bilug.linux.it/pipermail/linux/attachments/20110511/c05b6ce9/attachment.htm>