DragonFly kernel List (threaded) for 2008-05
Re: HEADS UP - Final HAMMER on-disk structural changes being made today
"Matthew Dillon" <firstname.lastname@example.org> wrote in message
I will be committing the final on-disk structure adjustments a little
later today. When these changes go in, anyone testing HAMMER will have
to newfs_hammer w/ the changes.
These are the last set of changes I expect to make to the on-disk
structures. These changes entail moving the crc fields to make crc
Also as-of today's later commit, HAMMER's CRC-checking will be enabled.
I guess this is probably a good time to ask.
Have you thought at all about how HAMMER will scale to the current
of NAND-based disks, and solid state storage in general? From my high level
understanding of the media and HAMMER in general I can hypothesize that it
looks like it will map fairly well in many respects, at least, much better
any traditional filesystem intended for magnetic storage. Purpose-specific
filesystems all gravitate toward being log-based and do buffering and
in a fairly similar manner to HAMMER. Current NAND (as far as I understand)
chips also operate on 16k blocks (you have to issue an erasure before a
There are various other things that these purpose-specific filesystems try
which is more media-specific, like spreading erasures/writes evenly over the
in an attempt to extend the life of the disk, re-mapping bad blocks, etc.
LogFS,JFS2,YAFFS). Considering how well much of this seems to map to
HAMMER's on-disk layout, and considering any of the extra higher-level bits
could likely be integrated "when the time is right" without much pain. It
wonder if you took solid state disks into consideration or if things just
worked out that way. Also, if you have any plans or ideas to see HAMMER be
performant on SSD's?
I wanted to go into more detail here and a couple weeks ago I even emailed
a couple of SSD manufacturers to inquire as to whether there were any (or
proposed) standards or methods of device inspection. For attempting to do
things like block allocation to exploit per-nand-chip performance, etc.
(None of them have gotten back to me). At any rate, a higher level email is
probably more palatable anyway :)