Date: Tue, 31 Aug 1999 03:31:35 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: ticso@cicely.de (Bernd Walter) Cc: tlambert@primenet.com, ticso@cicely.de, freebsd-fs@FreeBSD.ORG Subject: Re: fs-locking and fs memory copies questions Message-ID: <199908310331.UAA13295@usr04.primenet.com> In-Reply-To: <19990829013655.E27811@cicely8.cicely.de> from "Bernd Walter" at Aug 29, 99 01:36:56 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > This is the problem with growing FS's: the hash fill on the > > preexisting cylinger groups will be higher than on the new > > cylinder groups, leading to fragmentation. > > Mmmmm - I can't follow you on this. > The existing cg's are prefilled with old files. > The new ones are empty after growing. > I beleaved ffs would prever the new ones automaticaly because of > the super-blocks summary information. I don't think so. You'd want it to, but it probably won't. The problem that happens if it, in fact, does, is that you'd end up with data for new files clustering in one area of the disk, which is exactly the situation you wanted badly enough to avoid that you picked a hash-like algorithm (think of FFS as hashing to pick the blocks it's allocating) in the first place. This is why I said "Bad:" when referring to doing this on purpose, and not knowing when to stop. Create a couple of large files, and your allocation policy gets see-saw like. 8-(. > > A generic defragger would be a good think to have, if you wanted > > to allow shrinking partitions, too. > > I already need to move blocks around in case the superblock-summary > information needs another frag. > It was one of the more difficult things to do there are still some > erros left about this - the rest was quite easy. > Shrinking is something I don't beleave to get working properly, because > that would mean loosing cg's with all their inodes. > Moving files to different inodes is generaly a mess for NFS-servers. > Another point is that finding the reference for a frag is a real > expensive thing to do :( I agree on the frag, but if you are doing it in the background, you might not really care about the expense. The NFS inode problem can be resolved by virtualizing the inode numbers in the handled, but it's rather a pain to keep a table around for that. Like see-saw allocations, it hard to know when to stop doing it, once you start. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?199908310331.UAA13295>