DragonFly BSD
DragonFly users List (threaded) for 2010-02
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: appropriate location for hammer snapshots


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Thu, 11 Feb 2010 21:12:57 -0800 (PST)

:Hi,
:
:After upgrade to hammer version 4 and running 'hammer cleanup' the
:location of snapshots was changed from <pfs>/snapshots to /var/hammer.
:My problem is that my /var partition is UFS and not hammer and thus
:not mirrored.
:
:Changing the location of snapshots from <pfs>/snapshots removed the
:snapshots directory from both the PFS and its mirror. So if I lose the
:first disk with PFS Master then I will lose all the snapshots since
:they are not in the PFS slave.
:
:Is it ok to move the snapshots back to the PFS and put symlinks from
:/var/hammer to it?

    The softlinks are no longer the definitive recording of the snapshots
    in version 4.  The definitive recording is in meta-data in the HAMMER
    filesystem and should get mirrored (though I haven't tested this well)
    along with the rest of the filesystem.

    You can access all the snapshot TIDs using 'hammer snapls <fs>',
    on the master or on any slave.  They can be regenerated on the
    mirroring target's /var, in fact, though you'd have to write a
    little script (a nice side project would be to have a hammer
    utility directive which regenerates the softlinks from the
    meta-data), so they won't be lost.

    There are three problems with storing the snapshot softlinks in the
    HAMMER filesystem itself.  The first is when you cd into a snapshot
    you will see a snapshots directory with an older version of the
    snapshot softlinks many of which will be invalid.  So it creates
    confusion.

    The second problem is that snapshot management on the mirroring
    slave is independent of the snapshot management on the master.
    The original snapshots are transfered during the mirroring operation
    but once transfered you can manage the snapshots (and thus the
    freespace) on the mirroring target independently.  If the snapshot
    softlinks are part of the mirror then it will get awefully confused
    if you start trying to manage the snapshots on the mirroring target
    separately.

    The third problem is that the old methodology requires a snapshots
    directory in each fs (at least by default) which was kinda an eyesore
    and also reduced the flexibility of the filesystem and created further
    confusion if you cpdup'd it since the target fs wouldn't have the
    snapshots.

    So, I do not recommend putting the softlinks on each HAMMER FS.  Sure,
    /var is a hammer filesystem too but you get the idea.

:Will the next hammer upgrade and subsequent 'hammer cleanup' mess with
:the snapshots directory in the PFS? If so I guess giving it another
:directory name in the PFS would be better?
:
:Thanks
:
:Siju

    It will only try to migrate if it sees a <fs>/snapshots/config file.
    Hmm.  True, that's a bit hokey.  It could probably be cleaned up
    by having the cleanup utility check for config meta-data and not
    try to migrate again if the config meta-data exists.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>



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