Re: Expanding existing Hammer FS

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:Hi,
:
: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:
:
:       /etc/hammer/label
:
:   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
    hammer utility.

:   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
:
:Any suggestions?
:
:Regards,
:
:   Michael

    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).

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>