HAMMER update 19-June-2008 (56C) (HEADS UP - MEDIA CHANGED)

[Matthew Dillon]

:Pardon my ignorance if I am missing something, I haven't looked much
:into HAMMER yet.
:
:Will the FS have the same atomic update features that UFS has? Meaning
:fsync(2) returns only when all directory entries are safely on the
:disk (whether it's with softupdate-type ordering or journaling). It's
:important for mail servers and such so they don't lose messages at the
:time of powerfail/crash. If you dig around mailing lists, you'll find
:interesting stories how people who ran their FS mounted async (the
:default Linux EXT2/3 mount) for mail servers (and AFAIK at least on
:Linux in that case fsync returns early - not atomic, so software
:written with BSD behavior in mind wasn't safe to run without patching)
:found some of the messages in lost+found.

    Basically yes.  HAMMER maintains a dependancy hierarchy for directory
    entries and the related inodes, so if you create a directory structure
    and then fsync some file deep down in it it should fsync the directory
    entries as well.

    HAMMER does not have an async mount mode :-).  It will never have an
    async mount mode, in fact, but it doesn't need one.  Writing is so-well
    decoupled from the media that an async mode would not actually make
    things any faster.

    HAMMER's fsync might return early too, BTW... not intentionally, it's
    still an all-or-nothing deal from the point of view of crash recovery,
    but if the inode is already queued to the flusher it would have to be
    re-queued to get the rest of the modifications and that might cause
    fsync() to return early.  Doing it properly shouldn't be too difficult
    but it isn't at the top of my priority list.

:Also will there be a feature to grow/and or shrink the FS live without
:having to unmount? I can do this right now with XFS and LVM on Linux
:(grow, but not shrink), and its working amazingly well and very
:quickly to boot.
:
:Thanks.
:
:-- 
:Dan

    I haven't written the utility support but growing a HAMMER filesystem
    is fairly trivial.  All one needs to do is add the appropriate entries
    to the freemap.  Not only that, but also adding volumes to a HAMMER
    filesystem.

    HAMMER's freemap is a two-layer blockmap.  It is NOT pre-sized, and
    there is no block translation.  it works more like a sparse file whos
    size is the maximum possible size of a HAMMER filesystem (uh, that
    would be, uh, 1 Exabyte I think with the work done last week).

    Shrinking is also possible.  Not only shrinking, but also removing whole
    volumes.  Again, the feature hasn't been written yet and it would be a
    bit more time consuming because the reblocker would have to be run to
    clean out (aka copy out) the areas being removed, but there would be
    nothing inherently difficult about it and it certainly could be done
    live.

    p.s. if someone wants to make a side-project of it, go for it!

    Mirroring is at the top of my list for the release.  Frankly, the
    best way to resize a filesystem is to mirror and cluster, and then
    simply take the 'old' filesystem offline and completely redo it.
    Clustering is kinda the holy grail for the project and clearly won't
    be ready for this release, but it is something to think about.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>