DragonFly kernel List (threaded) for 2008-07
Re: How much are filesystem images trusted?
: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
: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.
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