Subject: [nfsv4] Rename over and notifications

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 14 Dec 2007 06:18:51 -0500

If I have a file A and we rename B to be A, we have an implicit delete.
The spec doesn't specify that this delete must be atomic with the rename
but it is for many implementations and applications certainly exist that
depend on the fact that you will always be able to open A.  Now consider
notifications.  We don't seem to have a provision for this case.  If we
reported with as a REMOVE_ENTRY followed by a RENAME_ENTRY, those two
entries culd be split apart into separate notifies, as we have been
discussing.  If you processed one before the other you might think where
was time when A didn't exist and reject a LOOKUP.
 
The obvious solution is to add a notify_remove4<1> to notify_remove4 and
notify_rename4. Keeping them separate but requiring that they be in the
same message seems like it will add to spec complexity/error.
 
Other ideas/opionions?
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Benny Halevy <[email-masked]>
Date: Fri, 14 Dec 2007 17:03:29 +0200

> same message seems like it will add to spec complexity/error.
I was under the impression that the server does not need to send a notify_remove4
before notify_rename4 if nrn_new_entry exists and that the client will update
its cache atomically with that respect.

I see two problems with that: first is that notify_remove4 also provides
nrm_old_entry_cookie to the client which I assume might change in this
rename case.  Second problem is with a rename over an existing name in
a different directories.  This will require a notify_remove4 and
notify_add4 on the target directory and a notify_remove4 of the old
name in the old directory, which naturally must be notified on a separate
callback.

I'm a bit concerned to actually propose that but some storage protocols
provide for linked commands... :)

Benny

---

From: Mike Eisler <[email-masked]>
Date: Fri, 14 Dec 2007 08:23:05 -0800 (PST)

--- "Noveck, Dave" <[email-masked]> wrote:

I'm not sure why I care about too much about accommodating servers
that don't have atomic delete. 

> was time when A didn't exist and reject a LOOKUP.

With notifications we would process non-atomic rename as an ADD and
a REMOVE.

If the rename was atomic but between two directories with notifications
enabled, we would process it as as REMOVE from dir X and an add to dir
Y. It has the appearance of non-atomic, but I'm sure that right
now I don't want to deal with two directory notifications in the
spec.

---

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 14 Dec 2007 11:35:10 -0500

> that don't have atomic delete. 

I don't either and that's why I didn't suggest anything that would
do so.

The issue I have is how do notifications accommodate servers that do
a rename atomically including the deletion of the renamed-over file.

---

From: Mike Eisler <[email-masked]>
Date: Fri, 14 Dec 2007 08:53:10 -0800 (PST)

> a rename atomically including the deletion of the renamed-over file.

And I don't understand why the server that does atomic rename would
not send a singloe notification: RENAME.

> > notifications.  We don't seem to have a provision for this case. 
> If
> > we
> > The obvious solution is to add a notify_remove4<1> to
> notify_remove4
> > and

---

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 14 Dec 2007 12:08:26 -0500

He may send a RENAME if source and target are the same directory.

Or and ADD and DELETE if they are different.

In each case, there may be a renamed-over file associated with the
RENAME or the ADD.

It seems to me that if I get an add and the file named in the add
already exists, I would say that the either the server or I has messaed
up.  I guess we could say "this must be a rename-over" and go on, but
I'd be more comfortable if I knew the server had the same view of things
as I did.

---

From: Mike Eisler <[email-masked]>
Date: Sat, 15 Dec 2007 08:01:21 -0800 (PST)

Now I understand you. I agree. The notification
need to have the renamed over file included, and the
notification should be atomic.

--- "Noveck, Dave" <[email-masked]> wrote:

> > > but it is for many implementations and applications certainly
> exist
> > > that
> > > discussing.  If you processed one before the other you might
> think
> > > where
> > > notify_rename4. Keeping them separate but requiring that they be
> in
> > > the

---

From: Benny Halevy <[email-masked]>
Date: Sun, 16 Dec 2007 09:34:16 +0200

>> I'd be more comfortable if I knew the server had the same view of

Note that for rename there could be up to two entries removed
(old entry, renamed over entry) and one added.
How about the following changes that use notify_remove4 in both
removal cases: (the rational is that the client wants 
nrm_old_entry_cookie in any case a name is removed)

+   union notify_renameover4 switch (bool nro_valid) {
+   case TRUE:
+           notify_remove4      nro_entry;
+   case FALSE:
+           void;
+   }

    struct notify_add4 {
+           notify_renameover4  nad_old_entry;
            notify_entry4       nad_new_entry;
            /* what READDIR would have returned for this entry */
            nfs_cookie4         nad_new_entry_cookie<1>;
            prev_entry4         nad_prev_entry<1>;
            bool                nad_last_entry;
    };

   struct notify_rename4 {
-          notify_entry4   nrn_old_entry;
+          notify_remove4  nrn_old_entry;
           notify_add4     nrn_new_entry;
   };

Benny