kernel work week of 3-Feb-2010 HEADS UP

[Michael Neumann]

2010/2/5 Matthew Dillon <dillon at apollo.backplane.com>
: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 volume
:would then be the regular hard disk. Maybe we'd need to give newfs_hammer
:a 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
:is
:a good idea?
:
:Regards,
:
:  Michael

    Not for newfs_hammer.  It would be a good fit for the hammer
    volume-add directive, though.Okay, I was just thinking about the lowest hanging fruit, and changinga few lines in newfs_hammer (basically just the space calculations) 
seemed to be those fruits :) 
   You could add a feature where it adds the volume and moves the
    UNDO FIFO into it.  volume-del might also have to be adjusted to
    move the UNDO FIFO back out (I don't recall offhand if it moves
    UNDO blocks).It doesn't move UNDO yet. Right now, the UNDO log is always onthe root volume, but when we add another volume, we allocate thesame space on the new volume for the UNDO log. So at least we 
are well prepared for moving the UNDO.Your idea sounds good, and would lead us to one step closer toroot volume removal.Could I implement moving the UNDO log by flushing everything to disk, so
that the UNDO log gets empty and then simply switching the log to thenew one? IIRC, writing an UNDO entry required the root volume to beupdated in HAMMER versions <= 3, which is no longer true as of V4.
Regards,  Michael