kernel work week of 3-Feb-2010 HEADS UP

Michael Neumann michaelneuma at googlemail.com
Thu Feb 4 17:05:58 PST 2010


2010/2/5 Matthew Dillon <dillon at apollo.backplane.com>

:...but you are leaving some room for also using it as a write cache later,
:right?  Whether it's some special hook for HAMMER's un/redo log, or
:something completely filesystem agnostic, it seems it could be a huge
:benefit to some applications. (like databases?)
:
:Just thinking out loud: if you have some resident-like way of "locking"
:data on the SSD, that might be an interesting way to get something similar
:to ReadyBoost.  (That would perhaps make for a neat GSoC project?)
:
:MAgnus

    Yes, it's theoretically possible by creating a small partition
    on the SSD (separate from the swap partition) and assigning
    all of HAMMER's UNDO FIFO disk blocks to it.  That would make
    fsync() considerably faster (65uS instead of 4-10ms).  It's
    not on my personal TODO list though.Btw, that should be already possible using multiple HAMMER volumes. The SSD partition should be made the root volume. It can be very 
small, so that only the UNDO log fits on it (maybe a GB?), the second volumewould then be the regular hard disk. Maybe we'd need to give newfs_hammera specific option so that it treats all space of the first volume as UNDO and
uses the second volume for storage. I think I can implement that. Matt, do you think the option to newfs_hammer isa good idea?Regards,
  Michael




More information about the Kernel mailing list