Re: [PATCH] btrfs: don't return EINTR

[Chris Mason <chris.mason@oracle.com>]

On Tue, Apr 17, 2012 at 03:14:24PM -0400, Josef Bacik wrote:
> On Tue, Apr 17, 2012 at 08:56:11PM +0200, Arne Jansen wrote:
> > On 04/17/12 20:22, Josef Bacik wrote:
> > >On Tue, Apr 17, 2012 at 11:24:01AM -0400, Chris Mason wrote:
> > >>On Tue, Apr 17, 2012 at 04:15:32PM +0200, Arne Jansen wrote:
> > >>>On 14.04.2012 14:56, Arne Jansen wrote:
> > >>>>It is basically a good thing if we are interruptible when waiting for
> > >>>>free space, but the generality in which it is implemented currently
> > >>>>leads to system calls being interruptible that are not documented this
> > >>>>way. For example git can't handle interrupted unlink(), leading to
> > >>>>corrupt repos under space pressure.
> > >>>
> > >>>Is this patch a candidate for the next rc?
> > >>
> > >>The EINTR came from Josef.  We do want to be able to break out of long
> > >>flushes, but I want to check with him to see if there was a specific bug
> > >>this was solving?
> > >
> > >Sorry I was -ENOINTERNET, no the only thing I was fixing was being able to break
> > >out of long flushes.  Maybe instead of using the big hammer here we just make
> > >unlink ignore EINTR and try again, or maybe pass down a flag saying I can't be
> > >interrupted?  Thanks,
> > >
> > 
> > unlink() is the only call I've seen problems with, but there are
> > probably other calls where EINTR is also unexpected.
> > Also, just retrying the unlink internally won't help as the signal
> > is still pending.
> > How can we gather a list of calls where EINTR is ok?
> 
> Well then passing a flag down that says we can't interrupt I guess is what we're
> going to have to do and just wait uninterruptible.  I think our best bet is to
> just fix them as they come up, I thought all system calls could return EINTR but
> apparently I was wrong :).  Thanks,

I'd guess that EINTR is unexpected most of the time.  Including in reads
and writes.  The real question is how long we might end up waiting?

-chris