Date: Tue, 31 Aug 1999 08:45:45 +0200 From: Bernd Walter <ticso@cicely.de> To: Terry Lambert <tlambert@primenet.com> Cc: Bernd Walter <ticso@cicely.de>, freebsd-fs@FreeBSD.ORG Subject: Re: fs-locking and fs memory copies questions Message-ID: <19990831084545.A32008@cicely8.cicely.de> In-Reply-To: <199908310331.UAA13295@usr04.primenet.com>; from Terry Lambert on Tue, Aug 31, 1999 at 03:31:35AM %2B0000 References: <19990829013655.E27811@cicely8.cicely.de> <199908310331.UAA13295@usr04.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Aug 31, 1999 at 03:31:35AM +0000, Terry Lambert wrote: > > 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-(. > OK - my programm is nearly complete for working offline so I will bring it to end. Then I will do some tests how blocks get filled up after that. It's only a performance issue, so I'm shure I will be happy with it anyway. > > > > 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. Doing it in the background might be a good solution when doing it online. At this moment I begin with increasing the strucktures - then writing the CGs including the expanded after that I reallocate some frags if needed and finaly rewrite the superblocks. It looks like the order is not the best one - I will need to rearange it. > > 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-(. Yes and you may want to make it persistence that a reboot won't mess things up. Is NFS the only critical case? If yes it would be possible to check if it's exported and take special care in single-user mode and if exported One thing is clear - if we can't decrease the fs and the user needs to he will ending up with backup-repartition-restore and running into exactly the same troubles. A simple warning to remount all clients should be the best way and maybe optionally such a translation table. At this moment I'm thinking more about features like automaticaly increasing. Say you have n-partitions and don't want to have them to get overfilled. You would define a spare-pool and if one partition gets filled over a defined limit a disk from the sparepool will be taken and added automatically. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de 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?19990831084545.A32008>