Logical volume management

Brian Candler B.Candler at pobox.com
Fri Nov 18 03:43:12 PST 2005


Vinum's manpage makes my head spin. I was wondering if anyone had considered
implementing something a bit more straightforward and also more dynamic.

Suppose you:

(1) Divide all your disks up-front into equal sized chunks, say 4MB.

(2) Use an indirection table to map each volume into an arbitary set of
    these chunks across all available disks.

(3) Store the indirection table at the end of a partition, as other GEOM
    modules do for their metadata, and cache it in RAM.

(e.g. a 160GB drive, divided into 4MB blocks, each of which has a 32-bit
indirection table entry, would require only 160KB of indirection table)

Why do this?

- You can install a system with minimal /, /usr, /var and /home, and then
grow each one in small increments as needed just by adding spare chunks.
With vinum you would end up with an increasingly complex configuration with
more and more subdisks, since each subdisk must be a contiguous range of a
physical drive. If you decide to get rid of a volume, then you need to keep
track of those subdisk fragments. I'm not sure if it's possible to take an
unused subdisk and split it so you can assign part of the free space to
another volume. Even if you can, this still means more subdisk
fragmentation.

With the above scheme an unused volume just returns its chunks into the pool
for reallocation.

- You can identify 'hot' chunks and move them between disks. This is a lot
more flexible than fixed striping. Unlike striping, it could distribute load
between unevenly matched devices (e.g. 10GB on one disk and 20GB on
another). It could also migrate 'hot' data to faster devices, such as a
battery-backed RAM disk[*]. With the right tools, this could all happen
automatically.

- Mapping volumes in fixed chunks in this way lends itself well to
visualisation, e.g. all chunks belonging to the same volume can be shown as
blocks in the same colour.

- What I'm suggesting may or may not look like Linux's LVM; I've never used
that. If its data structure is suitable, we can just use that and gain some
compatibility for multi-boot systems.

I guess you could work this way in vinum, dividing all your storage up front
into 4MB subdisks, but it doesn't sound like fun to me.

I also guess there's a lot of devil-in-the-details to do with marking a
volume as 'up' or 'down'; but hopefully mirroring and RAID could be
delegated to other GEOM modules, leaving us just with logical
{volume,extent} to physical {drive,extent} mapping to do.

Has something like this been proposed, discussed and/or discarded before?

Thanks,

Brian.

[*] e.g. http://uk.giga-byte.com/Peripherals/Products/Products_i-RAM%20(Rev%201.1).htm


More information about the freebsd-current mailing list