Logical volume management
Brian Candler
B.Candler at pobox.com
Fri Nov 18 04:59:38 PST 2005
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@?
Good idea.
Regards,
Brian.
More information about the freebsd-current
mailing list