Well, one example of volume management would be, say, to cut-up a
large drive into 1G pieces and map them to logical partitions.
Individual partitions could then be expanded or contracted
trivially (with a 1G granularity) simply by adjusting the mappings,
without having to shift tons of data around. The filesystem would
only have to deal with make-bigger and make-smaller operations.
Such a manager would also be able to 'move' pieces between physical
drives without any awareness needed by the filesystem... another
way to do data migration between drives.
One advantage of HAMMER is that the a filesystem partition does not
have to be fine-grained. It can be large and PFSs can be used to
break it down into smaller pieces. A per-PFS quota feature
(one of the possible GSOC projects) can control disk use within
each PFS. This means that the volume management does not have to
deal with tiny slivers of paritions. Even 1G might be smaller
than needed. 16G would be perfect for a terrabyte+ drive.
We already have volume add/remove code in HAMMER (though the
remove code can't remove the root volume). The next logical step
is to enhance that code to allow individual volumes to be expanded
or contracted under the control of a volume manager.
-Matt
Matthew Dillon
<dil...@backplane.com>
