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