Subject: RE: [nfsv4] Mandatory

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 22 Jan 2004 07:54:56 -0800

> in order to conditionally truncate files in one large atomic gulp...

A (macro)-molecular gulp, please.  It's already been established
that COMPOUND is not atomic :-)

-----Original Message-----
From: Trond Myklebust [mailto:[email-masked]]
Sent: Thursday, January 22, 2004 10:45 AM
To: Noveck, Dave
Cc: [email-masked]; Stevan Steve Allen; [email-masked]
Subject: RE: [nfsv4] Mandatory

På on , 21/01/2004 klokka 18:42, skreiv Noveck, Dave:
> Right :-(
> 
> One way to do this is to define a new special stateid to mean
> the last stateid returned by any previous op in the compound
> which generated a stateid.
> 
> How about a stateid whose other field is all zero and whose
> seq value is one?  We would reserver all the other possible
> values of seq for stateid's whose other field is all zero
> which should good us enough special stateid's for many minor
> versions to come :-) 

Would OPEN_CONFIRM obey this too? If so, I see a future of compounds of
the form

OPEN+OPEN_CONFIRM+SETATTR+CLOSE

replacing the existing 3 or 4 RPC calls that are required in order to
satisfy a truncate() request on a closed file.

If you add the rule that the special stateid with seq value is 2 refers
the last-but-one stateid, then you could even do stuff like

OPEN+OPEN_CONFIRM+LOCK+NVERIFY+SETATTR+LOCKU+CLOSE

in order to conditionally truncate files in one large atomic gulp...

8-)

Cheers,
  Trond

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

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 22 Jan 2004 11:08:57 -0500

> that COMPOUND is not atomic :-)

...but if you add the ability to do (mandatory!) byte range locking and
OPEN w/ deny modes within the compound itself, then it can be made
atomic for all intents and purposes. 8-)

Cheers,
  Trond

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 22 Jan 2004 11:25:42 -0500

> atomic for all intents and purposes. 8-)

To clarify:

Your "atomicity requirement" here is not the same as full COMPOUND
atomicity.

The purpose of doing the NVERIFY in the context of truncate here is to
check whether or not anybody has changed the file while you weren't
looking (I'm assuming that your client doesn't already have a write
delegation to the file). You then want to ensure that the conclusions of
that NVERIFY remain valid until the SETATTR completes.

i.e. the point of the whole exercise is to add the ability to enable the
creation of sub-collections of operations within the COMPOUND that are
"atomic". That is, after all, exactly what you are asking for in your
initial request for allowing LOCK+WRITE+LOCKU.

Cheers,
  Trond

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 22 Jan 2004 11:42:38 -0500

> atomic for all intents and purposes. 8-)

This would make the RESOURCE error recovery problems a bit more
pressing, since the way most servers are written now I get the
impression they'd be likely to return RESOURCE if you tried something
that complicated.

--Bruce Fields

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 22 Jan 2004 11:54:07 -0500

> impression they'd be likely to return RESOURCE if you tried something

No existing servers have implemented Dave's proposal. This is a future
extension.

Note, though, that even replays of LOCK+WRITE+LOCKU are going to be fun
to deal with, since they involve bumping the sequence number at least
twice...

Cheers,
  Trond