Re: How much are filesystem images trusted?

["Dionysus Blazakis" <dion.blazakis@xxxxxxxxx>]

On Fri, Jul 25, 2008 at 3:16 AM, Matthew Dillon
<dillon@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
> :point.
> :
> :-- 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
>    references.

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.

-- Dion

>
>                                        -Matt
>                                        Matthew Dillon
>                                        <dillon@backplane.com>
>