Subject: Re: [nfsv4] Sleepy clients

From: [email-masked]
Date: Sun, 28 Aug 2005 15:40:49 -0400 (EDT)

>   1 - It seems to me that a client might want to prevent other clients from
>       performing conflicting writes while it is asleep. (Open_share_deny_both
>       would do that, if only the sleepy client could maintain the lease.)
> 
> That seems very anti-social to me.  Write conflicts are rare, and when they
> do happen, I'd rather give priority to the connected clients. 

Is it anti-social to not want someone else editting a file while you are?
(Suppose a marketing doc that someone takes on the plane in their laptop,
 that others in the same marketing group are involved in.)
In the programming world, source code control systems were invented to
deal with these things. It seems to me that an intermittently awake
client could use something along the lines of a "source control system
behind the curtain" so to speak.

What might be considered a more social variant would not stop the connected
clients from having access, but would put a "flashing red message" on their
screen "Change this file at your peril, since Fred has it on his laptop".

>  How do you
> know the disconnected client will ever come back?  What will you do if it
> doesn't?

Therein lies the rub. I suspect my above example would result in some
frantic cellphone calls when others can't get access to the document, if
the guy on the plane doesn't reconnect soon enough. The management of
disconnected clients is going to be extremely challenging because of this.
(For example, the "source code control system behind the curtain" might use
 a combination of techniques to "release" a file for other access. Cell
 voice message, cell text message, email to the user's blackberry... At
 some point manual intervention by a sysadmin might be required, I think.)

All of this adds up to why I stated "might" in the first sentence, above,
and why some sort of versioning for the file system "might" be an attractive
alternative.

>   2 - A client might want to be able to modify a file on the server when it wakes
>       up without destroying other changes done by other clients while it was
>       asleep. In other words, versioning.
> 
> It would be silly to just overwrite.  The disconnected client must detect
> conflicts when it reconnects.  You don't need versions at the server, just
> at the client, and you only need two, maybe three.  A linear versioning
> system like VMS isn't really right, because the two versions both diverge in
> parallel from a common ancestor.  Disconnected afs calls them by the
> original name and the original name .something then lets the user decide
> which to keep.

That sounds like a good start. What happens when 5 different users have
5 different local copies of the marketing document? There
is also the issue of "not so knowledgeable" users who don't want to know
anything about versions and just expect the system to work it out for them.
(A "smart" document system could merge the different versions, but only if
 it has all those versions accessible together and not on different clients.)

Make no mistake. I am far from knowledgeable about disconnected operation,
but it is an interesting problem to ponder, rick.

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

---

From: David Robinson <[email-masked]>
Date: Sun, 28 Aug 2005 23:35:00 -0500

> screen "Change this file at your peril, since Fred has it on his 

We could do such a thing within NFS, but do we really want to?
My perspective that this sort of this is best left to
a middleware solution. In fact, in VMS the versioning was
handled the the RMS middleware, not the Files-11 filesystem.
If you did straight SYS$QIO calls you had no explicit semantics
of versions, it was just a weird part of the name.

> but it is an interesting problem to ponder, rick.

Disconnected operation is hard, often the merging and managing
of data on reconnect is best left to middleware that has
knowledge about file formats, logical records, or other bits
that allow intelligent merging.

If NFSv4 is missing things to facilitate such smart software,
we should consider it.  But I haven't heard anything so far.

	-David

---

From: "Talpey, Thomas" <[email-masked]>
Date: Mon, 29 Aug 2005 08:15:54 -0400

>screen "Change this file at your peril, since Fred has it on his laptop".

Isn't this an application-specific thing? For example, MS Office
does exactly this, by writing your name and edit status into the
file you're working on. Subsequent opens find this "metadata"
and do just what you describe.

In other words, do we really want the filesystem doing this?

Tom.