DragonFly kernel List (threaded) for 2008-12
DragonFly BSD
DragonFly kernel List (threaded) for 2008-12
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Expanding existing Hammer FS


From: Michael Neumann <mneumann@xxxxxxxx>
Date: Tue, 16 Dec 2008 20:53:01 +0100

Am 16.12.2008 20:28, schrieb Matthew Dillon:
: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.
Yes, I think that is done by format_volume (initialize_freemap).

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

Okay. But adding a volume also means formatting it. So I guess I have to add an option to newfs_hammer to allow to initialize (format) a single volume, without generating a filesystem.

:   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

Hm, but what happens after a reboot? It won't boot anymore, without making a change to /etc/fstab. Ideally this information would be stored in the root volume (or maybe somewhere else?).

So the sequence of expanding a HammerFS would then be:

  # newfs root volume
  newfs_hammer -L label /dev/ad0

mount_hammer /dev/ad0 /hammer

  # prepare (format) a volume
  newfs_hammer -L label -F /dev/ad1

  # and add it to the filesystem
  # (checks if label of root-volume and that of /dev/ad1 matches)
  hammer add-volume /hammer /dev/ad1

reboot

mount_hammer /dev/ad0 /dev/ad1 /hammer

Regards,

Michael



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]