No, it isn't a volume manager, it's simply that the filesystem

    can be made up of multiple volumes.  Each cluster (say, a 256M chunk)

    is integrated into the filesystem-wide B-Tree and can only be addressed

    by its parent or by the parent pointers of its children.  This means

    that clusters can be migrated with minimal work and thus can be migrated

    while the filesystem is live.  We don't have the situation such as we

    have in UFS where random inodes in the filesystem directly reference

    random data blocks elsewhere in the filesystem.
    For example, if you had a HAMMER filesystem backed by two volumes you

    could add a third volume, migrate all the data from the first volume

    to the new volume, and then remove the first volume (make it not part

    of the filesystem any more).  Similarly you could migrate the clusters

    at the end of a volume elsewhere and then contract that volume, or

    you could expand a volume and tell HAMMER to use the new space.
    I am not going to try to implement RAID inside HAMMER when RAID can be

    done with a software or hardware solution in another layer.
    HAMMER will do what hardware and software storage solutions can't

    easily or efficiently do, which is logical replication of the entire

    filesystem.  A logical replication allows the different replication

    targets to retain varying amounts of filesystem history.  For

    example, your production filesystem might retain 30 second snapshots

    for an hour and hourly for the day, while one of your replication

    targets might retain hourly snapshots for a day and daily snapshots

    for a month, etc.
    Ultimately we will have a multi-master environment which will silently

    handle whole or partial filesystem failures.  In this case the type

    of redundancy you need at the storage layer will depend on the number

    of physical disks you need to use for each copy of the filesystem.  If

    your filesystem fits on one or two physical disks th...
[ message continues ]

This is the functional equivalent of a RAID1, and that is all HAMMER

provides; the point of RAIDZ (and RAID3,4,5,6,etc) is that you don't

need 2n bytes worth of disk for n bytes worth of usable storage, yet

keeping some level of resilience. There is something to be said for this

kind of scheme, namely not wasting as much disk space, but in the case

of RAID1,0,10,01, moving that to a different layer (e.g. Vinum) is good

enough.
In a clustering environment, it's not likely that you'll want anything

other than full replication, but at least on single-node storage

systems, using storage more efficiently has its uses; even though it

means longer recovery times.
Cheers,

--

         Thomas E. Spanjaard

         tgen@netphreax.net