Date: Tue, 16 Nov 1999 13:39:14 -0800 (PST) From: Alfred Perlstein <bright@wintelcom.net> To: Zhihui Zhang <zzhang@cs.binghamton.edu> Cc: freebsd-fs@FreeBSD.ORG Subject: Re: On-the-fly defragmentation of FFS Message-ID: <Pine.BSF.4.05.9911161331090.12797-100000@fw.wintelcom.net> In-Reply-To: <Pine.GSO.3.96.991116143730.11223A-100000@sol.cs.binghamton.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 16 Nov 1999, Zhihui Zhang wrote: > > On Tue, 16 Nov 1999, Alfred Perlstein wrote: > > > On Tue, 16 Nov 1999, Zhihui Zhang wrote: > > > > > > > > After studying the code of ffs_reallocblks() for a while, it occurs to me > > > that the on-the-fly defragmentation of a FFS file (It does this on a per > > > file basis) only takes place at the end of a file and only when the > > > previous logical blocks have all been laid out contiguously on the disk > > > (see also cluster_write()). This seems to me a lot of limitations to the > > > FFS defragger. I wonder if the file was not allocated contiguously > > > when it was first created, how can it find contiguous space later unless > > > we delete a lot of files in between? > > > > > > I hope someone can confirm or correct my understanding. It would be even > > > better if someone can suggest a way to improve defragmentation if the FFS > > > defragger is not very efficient. > > > > > > BTW, if I copy all files from a filesystem to a new filesystem, will the > > > files be stored more contiguously? Why? > > > > > > Any help or suggestion is appreciated. > > > > I think you're missing an obvious point, as the file is written out > > the only place where it is likely to be fragmented is the end, hence > > the reason for only defragging the end of the file. :) > > > > Thanks. I think this defragmentation (I can not find a better word for it) > means making the blocks contiguous. Consider the case which in the last > eight blocks of a file, seven of them are already contiguously allocated > and only the last block is not. Now if we write at the very last block, > the filesystem will try to move those seven blocks and the last block > together to some other place to make them all contiguous. This only > happens at the end of a file. I was wondering if this can happen > elsewhere or if there is a better solution for this kind of adjustment. Not to my knowledge, however if it only works on the tail end of files (which I'm 99% sure is true) then Julian's point is a problem for this algorithm, (files with holes) it may be smart to try to reallocblks on 64k cluster boundries. However this starts to get into adaptive algorithms, something that FFS already has plenty of. :) More couldn't hurt, insight, work and testing of such an algorithm would probably be very appreciated. One of the things that Kirk mused making adaptive was FFS's aggressive write-behind feature that can cause problems when the entire dataset fits into ram. It doesn't necessarily cause problems, execpt for the fact that linux has a more aggressive caching algorithm that will not write anything out until the cache is nearly full. Each approach has it's advantages and drawbacks, FreeBSD excels when the dataset is larger than ram, whereas Linux owns the show when it does fit into ram. An adaptive algorithm would be very benificial for this strategy. -Alfred > > -Zhihui > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9911161331090.12797-100000>