DragonFly kernel List (threaded) for 2008-12
Re: Expanding existing Hammer FS
:I'd be nice to be able to add just another spare disk to an existing
:Hammer FS to expand it's capacity. After taking a look at newfs_hammer,
:it seems to be pretty easy to do that:
: * run format_volume on the new disk
: * ondisk->vol_num += 1 (number of volumes)
: for each volume of the filesystem.
:I think that would be enough and I can hack it. My question is more
:API-oriented. How would the command line look like?
Almost. You also have to adjust the freemap to indicate
that the space is available. That is a bit more difficult but
not too difficult. Normally what you would do is allocate
space from the new volume itself for the freemap layer1 and layer2
pages involved, and then just map them into the master freemap's top
level array in the volume header.
: How about this:
: hammer newfs label [... specify some defaults...]
: will create the following file:
: which will list all devices that make filesytem "label".
In the hammer_newfs utility only, not in the main hammer utility.
The newfs function is just too dangerous to be in the main
: Now add a volume:
: hammer add-volume label /dev/ad0
: This will format /dev/ad0 and attach it to the filesystem
: "label" by iterating over all volumes in /etc/hammer/label and
: increasing the volume count.
: Of course it would be more beautiful if the root volume would
: store those device names. That would also ease mounting of
: a multi-volume HAMMER fs:
: # create multi-volume Hammer FS
: newfs_hammer /dev/ad0 /dev/ad1
: # mount multi-volume Hammer FS by specifying the root volume
: mount_hammer /dev/ad0
: # add /dev/ad2 to the filesystem specified by the root volume ad0
: hammer add-volume /dev/ad0 /dev/ad2
On hammer add-volume, you should specify the filesystem and the device
to add, not the original device(s). And it should only operate on a
live (already mounted) filesystem.
hammer add-volume /myhammermount /dev/ad2
hammer del-volume /myhammermount /dev/ad2
The hammer utility would implement the features via ioctl()'s into
the HAMMER VFS in the kernel.
It would be fairly straight-forward to implement add-volume.
del-volume is something I also really want to have and it is
possible to do by adding some code to 'block out' new allocations
from a volume, and then reblock the filesystem to move all the
data out of them. Special consideration for the undo FIFO and
freemap blocks would have to be made but the reblocker would handle
everything else (B-Tree nodes & data).