From owner-freebsd-fs Mon Aug 30 23:46:13 1999 Delivered-To: freebsd-fs@freebsd.org Received: from mail.du.gtn.com (mail.du.gtn.com [194.77.9.57]) by hub.freebsd.org (Postfix) with ESMTP id D57F415867 for ; Mon, 30 Aug 1999 23:46:07 -0700 (PDT) (envelope-from ticso@cicely8.cicely.de) Received: from mail.cicely.de (cicely.de [194.231.9.142]) by mail.du.gtn.com (8.9.3/8.9.3) with ESMTP id IAA21216; Tue, 31 Aug 1999 08:45:19 +0200 (MET DST) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10]) by mail.cicely.de (8.9.0/8.9.0) with ESMTP id IAA14813; Tue, 31 Aug 1999 08:46:00 +0200 (CEST) Received: (from ticso@localhost) by cicely8.cicely.de (8.9.3/8.9.2) id IAA32065; Tue, 31 Aug 1999 08:45:45 +0200 (CEST) (envelope-from ticso) Date: Tue, 31 Aug 1999 08:45:45 +0200 From: Bernd Walter To: Terry Lambert Cc: Bernd Walter , freebsd-fs@FreeBSD.ORG Subject: Re: fs-locking and fs memory copies questions Message-ID: <19990831084545.A32008@cicely8.cicely.de> References: <19990829013655.E27811@cicely8.cicely.de> <199908310331.UAA13295@usr04.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <199908310331.UAA13295@usr04.primenet.com>; from Terry Lambert on Tue, Aug 31, 1999 at 03:31:35AM +0000 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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