DragonFly kernel List (threaded) for 2008-06
Re: HAMMER update 19-June-2008 (56C) (HEADS UP - MEDIA CHANGED)
: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.
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
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
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.