New hammer utility feature in HEAD: 'hammer cleanup'
dillon at apollo.backplane.com
Mon Sep 22 17:10:57 PDT 2008
:It would be nice if hammer(8) included a command to list all PFSs
:(maybe pfs-status without arguments);
:this could be used for a general way to iterate PFSs.
:Is this info saved in a HAMMER fs?
:A few questions:
: - `hammer snapshot' is a per PFS operation, right?
It should be. I've gone over that code several times and it restricts
the scan to a single PFS, but I haven't actually tested that it works
: - Is null mounts the recommended way to use PFSs in general?
Yes, a null mount of the PFS softlink is a ton better then going
directly through the softlink. You get a real mount point so
userland expects the inodes to be in a different domain (which they
are). If you run through just a softlink userland can get confused
by the 'duplicate' inode spaces.
What I've been doing is creating PFS softlinks in <filesystem>/pfs/<name>
and then null-mounting it to where it is supposed to go.
: - Is PFS #0 (the hammer fs) a fully functional PFS
Yes. It is always PFS #0 and always a pfs-master. hammer pfs-downgrade
will not allow you to downgrade the primary filesystem to a slave as a
safety (though if you ran the ioctl() manually it would). The primary
filesystem can be used as a mirroring source but I don't want people
to use the primary filesystem as a mirroring target.
Note that primary filesystem (PFS#0) will not dive into other PFSs.
There is an issue with <filesystem>/snapshots which I haven't resolved
yet. If you mirror a PFS to a slave, <filesystem>/snapshots gets
mirrored as well, but you do not necessarily want the master's snapshots
to be the same as the slave's. So snapshots of mirroring slaves would
have to be stored elsewhere. I need to add some logic to detect that a
PFS is a slave and not try to access <filesystem>/snapshots when pruning
I'll have to think of how best to handle it. I do have extra fields
in the pfs data structure that I can use to store an alternative
snapshots directory location.
<dillon at backplane.com>
More information about the Kernel