Date: Sun, 6 Oct 1996 19:13:52 +1000 (EST) From: Darren Reed <avalon@coombs.anu.edu.au> To: terry@lambert.org (Terry Lambert) Cc: kpneal@pobox.com, terry@lambert.org, avalon@coombs.anu.edu.au, jrg@demon.net, mrg@eterna.com.au, hackers@freebsd.org, tech-kern@netbsd.org Subject: Re: VPS mailing list, BSD interest? Message-ID: <199610060915.CAA27478@freefall.freebsd.org> In-Reply-To: <199610031734.KAA06317@phaeton.artisoft.com> from "Terry Lambert" at Oct 3, 96 10:34:51 am
next in thread | previous in thread | raw e-mail | index | archive | help
In some mail from Terry Lambert, sie said: > > > Ok. Doesn't this assume that whatever is sitting on top of the partition > > is a filesystem? What if it isn't? What if a database or something or > > other is sitting on top? Would resizing be possible? Wouldn't the mechanism > > of communicating the resize be different because of the user program > > hitting the disk instead of going through a filesystem? > > You would only allow vetted changes. I there was a database (actually, > a private FS for a database) there, then the change would probably not > be vetted. If it's not vetted, it's disallowed (and a veto is given > using the default vetting code). What you might want to do is disallow changes (in size) to any partition that is "open" and is not of a (mounted) type which recognises shrink/grow dynamically. Growing a filesystem can be broken into two phases: * increasing the physical allocation map * initializing the new area (a la newfs) and making it recognisable However, when changing the size of a logical volume (i.e. "partition") you need not require that it be umount'd or not open. Being able to "rationalize" disk space would be nice too, so that if you've used 60% of a logical volume and want to reduce it to make space for elsewhere, you can make sure that 60% is compactly used and not scattered. If you're using something like ingres and have a logical volume set up for your log file, obviously you're going to need to rerun the ingres program that makes it usable by ingres. Another concept which might be useful is that of "contiguous allocation". It may be useful to require a swap area be contiguous. With respect to growing a swap area, why not just make a new swap area and swapon ? Darren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610060915.CAA27478>