How much are filesystem images trusted?

[Matthew Dillon]

:
:Sounds good.  I was struggling to make sure a forced read-only mount
:would not clean up the undo FIFO and flush.  My attempts would result
:in a flush somewhere (unmount?) and then the second time the image was
:mounted, it would mount cleanly (having emptied the FIFO).  I didn't
:get as much time this week to read through the code as I had hoped.

    It isn't supposed to do that.  The recovered buffers are B_LOCKED
    if the kernel tries to write them out, so only HAMMER itself should
    be able to flush them.

    The recovery code is fairly careful to not update the root_volume
    header on a read-only mount.  If the volume header is getting updated
    anyway at some point there could be a bug in the normal flusher
    operation.

:Yes, I believe so.  Could you explain that flag (io.recovered)?  I
:thought it was just to designate that some recovery had been done on a
:volume, but I'm not sure.
:
:-- Dion

    When the recovery code modifies a buffer as part of the recovery
    operation it adds an extra ref to the buffer (buffer->io.lock.refs)
    and sets io.recovered.  The io.recovered bit flags the extra the ref.
    The extra ref prevents the buffer from being flushed by the kernel.

    Theoretically a read-only mount then also prevents HAMMER from flushing
    any dirty buffers, referenced or otherwise (the only dirty buffers
    that might exist when you do a read-only mount would be io.recovered
    buffers).

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>