On Fri, Jul 25, 2008 at 3:16 AM, Matthew Dillon <[EMAIL PROTECTED]> 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 > <[EMAIL PROTECTED]> >
