HEADS UP - Final HAMMER on-disk structural changes being made today
Samuel J. Greear
dragonflybsd at evilcode.net
Mon May 5 20:16:08 PDT 2008
"Matthew Dillon" <dillon at apollo.backplane.com> wrote in message
200805051548.m45Fm0pI090056 at apollo.backplane.com">news:200805051548.m45Fm0pI090056 at apollo.backplane.com...
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
calculations easier.
Also as-of today's later commit, HAMMER's CRC-checking will be enabled.
-Matt
Matthew Dillon
<dillon at backplane.com>
Matt,
I guess this is probably a good time to ask.
Have you thought at all about how HAMMER will scale to the current
generation
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
than most/
any traditional filesystem intended for magnetic storage. Purpose-specific
flash
filesystems all gravitate toward being log-based and do buffering and
allocations
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
write).
There are various other things that these purpose-specific filesystems try
to do
which is more media-specific, like spreading erasures/writes evenly over the
media
in an attempt to extend the life of the disk, re-mapping bad blocks, etc.
(See
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
made me
wonder if you took solid state disks into consideration or if things just
sorta
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 :)
Thanks,
Sam
More information about the Kernel
mailing list