Re: [PATCH] NFS: have string-based mount options default to "intr" mounts

[Trond Myklebust <trond.myklebust@fys.uio.no>]

On Wed, 2007-07-25 at 16:36 -0400, Peter Staubach wrote:

> It sounds like the sync to disk on close() needs to be done in a
> separate context and have the process in close() wait on it?  That
> way, the process which received the signal could abort and return
> without waiting on all of the data to get flushed, but the data
> would still get flushed in a timely fashion?

We could do that, but what kind of extra guarantees would that provide?
The whole question is what you mean by "timely fashion" here. Normally,
I'd expect that to mean "before any locks are freed", in which case I
don't see how a separate flush context will help here...

> I suspect that as soon as you throw in a close() which returns
> EINTR, then all assumptions about close-to-open become null and
> void.

Exactly. Byte range locks will be automatically freed as part of the
POSIX close() process, and the application itself may still survive for
long enough to release other locks (dotlocks etc...) that it may hold.

Trond