Re: Logical volume management

On Fri, Nov 18, 2005 at 06:39:09AM -0600, Eric Anderson wrote:
> - volume migration (online)

Perhaps there are two primitive operations:

1. move an individual chunk from device A to device B
   (LVM calls these chunks "extents" BTW, which is probably a better name;
   it has a long history going back to mainframe storage systems)

2. move an entire volume

The second of these could be done by creating a new volume, mirroring it
with the first, and then removing the first volume from the mirror set.

> - auto block allocation (assigning blocks from the pool to a volume as 
> needed)

I think that requires interaction with the underlying filesystem if it is to
happen automatically. I'd be quite happy with a two-step process: increase
the size of a volume manually, then run growfs to make the filesystem fit
the new space.

Pity there's no shrinkfs...

> It would be nice to be able to create an arbitrarily large volume, which 
>  only uses these volume blocks (you call them chunks) as the volume 
> gets filled.  This way, you could create a 2Tb volume, with only a 
> single 200Gb drive, then as you neared the 200Gb used mark, you could 
> add another disk, and grow on to it

Maybe. However I don't see the advantage of this compared to creating a
200GB volume, and then as it nears getting full expand it to 400GB, and so
on.

I can see a number of downsides to your approach:

- df will lie. You may think your filesystem is only 10% full, when in fact
it is about to fail due to lack of space.

- partitioning has an important administrative use, to enforce limits. That
is, one of the reasons I keep /var on a separate partition is so that if it
fills, it doesn't stop the OS from creating files in / or /tmp etc, so it's
easier to recover from whatever problem was filling /var in the first place.

So if you have an 80GB drive and you created an 80GB /, an 80GB /var, an
80GB /usr and 80GB /home, allowing each of them to expand to fit as needed,
then you might as well just have created a single 80GB / in the first place,
mightn't you?

> Maybe we should take this to freebsd-geom_at_?

Good idea.

Regards,

Brian.