Re: [PATCH 2/3] enhanced syscall ESTALE error handling (v2)

[Miklos Szeredi]

> > I don't know what NFS does, but returning EINTR without actually
> > canceling an operation in the server is generally not a good idea.
> >
> >   
> 
> This is what NFS has been doing, for several decades, and no one
> has complained yet.

Is it really?  Man nfs says something quite different (emphasis mine):

   intr        If an NFS file operation has a *major timeout* and  it  is
               hard  mounted,  then  allow signals to interupt the file
               operation and cause it to return EINTR  to  the  calling
               program.  The *default* is to *not* allow file operations to
               be *interrupted*.

> >> Have you noticed another one?  I would be happy to chat with the
> >> developers for that file system to see if this support would
> >> negatively impact them.
> >>     
> >
> > Oh, I have no idea.  And I wouldn't want to do a full audit of all the
> > filesystems to find out.  But if you do, please go ahead.
> >
> >   
> 
> Well, you brought it up.  I thought that perhaps you had something
> other than FUD.

It's not FUD, it's being careful not to break an implementation when
changing an API in a backward incompatbile way.

> Please describe this real and existing fuse installation so that I can
> better understand the situation and the real requirements here.

I have already done so:

  "Also up till now, returning ESTALE in a fuse filesystem was a
   perfectly valid thing to do.  This patch changes the behavior of
   that rather drastically.  There might be installed systems that
   rely on current behavior, and we want to avoid breaking those on a
   kernel upgrade."

Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/