How much are filesystem images trusted?
dion.blazakis at gmail.com
Fri Jul 25 07:37:45 PDT 2008
On Fri, Jul 25, 2008 at 3:16 AM, Matthew Dillon
<dillon at apollo.backplane.com> wrote:
> :It consists of two small changes:
> : - Check that the tail_size is reported at least the size of a tail
> :fifo structure (instead of at least 0) -- this will cause an EIO
> :instead of a loop or panic.
> : - If an error occured in hammer_recover, an io lock leak caused a
> :panic. I now skip the (last) flush if an error occured during mount.
> :This seems safe -- doesn't matter too much, you're screwed at this
> :-- Dion
> I've got a patch set almost ready that includes your tail size
> check and adds a discard mode to the buffer flush so I can also
> call it from the umount code (read-only mounts that succeed must
> also discard the recovered buffers at umount time), plus also when
> the undo operation fails to get rid of the 'recovered' buffer
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.
> Is the io lock leak the 'recovered' designation issue? If so then I
> have it covered. If there is a different leak I could use a pointer
> to it.
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.
> Matthew Dillon
> <dillon at backplane.com>
More information about the Kernel