DragonFly users List (threaded) for 2010-02
Re: appropriate location for hammer snapshots
: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
: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
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
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
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?
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.