> > 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-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
