Subject: Re: [nfsv4] Sleepy clients

From: Jim Rees <[email-masked]>
Date: Mon, 29 Aug 2005 13:50:10 -0400

It reminds me of all the Unix apps. that do strange contorted things with
  "lock files" because the apps. don't use/trust file locking primitives.

Some of the contortions were only required in the old days before O_EXCL.

  1 - Must recognize that other clients are also doing so and know to
      create a new/different version, instead of just re-writing the file.

I disagree.  This would require changes in all clients, not just
disconnected clients, and it's an unreasonable burden to impose on them.
Disconnected clients should retain their own copy of the original file if
they think they will need it when they reconnect.

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Brent Welch <[email-masked]>
Date: Mon, 29 Aug 2005 11:47:48 -0700

>>>Jim Rees said:

Yup - let's make sure we know what the AFS disconnected operation effort has
learned in the last like 10 years of working on this.  The server just
has to provide enough help for clients to detect conflicts when they
reconnect.  This is the change attribute.  And the server has to be
forgiving with respect to lease revocation, which it sounds like most
servers are; they only revoke on conflict.  I think we're done here.

One thing I'm not sure about is how an NFSv4 client detects that it lost a
lock when it re-acquires its state.  You can infer that if the change
attribute is different then the file was modified, but there is a subtle
difference between having a file change and having someone else break your
lock.  It may not matter.

I suggest we see how far we can get with these two basic features
(change attribute and forgiving lease expirations) before we add
any more complexity to the server to support disconnected clients.

In other words, I have no mercy for the marketing guy with the
whole file lock that is on a flight to Europe.  His windoz app
will help him "Save As" the file and his colleagues can sort
things out later.  As a file server, I've done my duty if I've
allowed his client to detect the problem.

--
Brent Welch
Software Architect, Panasas Inc
Accelerating Time to Results(tm) with Clustered Storage

www.panasas.com
[email-masked]

---

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 29 Aug 2005 14:55:37 -0400

On Mon, Aug 29, 2005 at 11:47:48AM -0700, Brent Welch wrote:
> lock.

8.8: "When it is possible that the lease period has expired, the client
must validate each lock currently held to ensure that a conflicting lock
has not been granted.  The client may accomplish this task by issuing an
I/O request, either a pending I/O or a zero-length read, specifying the
stateid associated with the lock in question.  If the response to the
request is success, the client has validated all of the locks governed
by that stateid and re-established the appropriate state between itself
and the server."

(What's the correct error for the server to return in this case?)

> It may not matter.

Isn't it common for an application to use locks on one file to serialize
changes to a completely different file?

--b.