From: Noveck, Dave (dave.noveck@netapp.com)
Date: 03/13/00-09:11:33 AM Z
Message-ID: <F6C5585BF0CED311B58D009027C2299C47C016@tahoe.corp.netapp.com>
From: "Noveck, Dave" <dave.noveck@netapp.com>
Subject: RE: attributes of renamed file
Date: Mon, 13 Mar 2000 07:11:33 -0800
I think that in this case COMPOUND solves the problem, despite
the lack of atomicity, at least when handles are persistent.
Suppose you always follow a RENAME by a LOOKUP of the new name
(and then a GETFH, GETATTR after that). If you use the
information you get back properly, the lack of atomicity
means that you may not know for sure what file got renamed
but you nonetheless have enough information to properly
update any client name and attribute caches.
Assume, without loss of generality, that everything is happening
in a single directory. Suppose client 1 opens a file A and that
that file had handle h0. You are going to cache the mapping of
the name A to handle h0 (or more properly, the vnode associated
with handle h0) and also cache attributes associated with that
vnode. Suppose that at some later time, you do a rename of
A to B which is followed by a LOOKUP of B and then a GETFH
and GETATTR.
We can now update the name and attribute caches as follows:
If the LOOKUP of B found the handle h0, then we
can update the cached attributes associated with h0
and update the name cache by deleting the entry for
A and adding one for B. We will be in this case most
often if in fact the RENAME renamed what we thought
we renamed, but not always (see below).
If the LOOKUP of B found a handle other h0 (call it h1),
then we update any attribute cache entry we have for
h1 to reflect the new attributes. We may also, if we
choose, create a new attribute cache entry for h1 if
we don't already have one. We purge any name cache
entries that point to h0 (since we have no idea what
h0 is named) and also should purge the attributes
cached for h0, since it was renamed by someone and
we don't know when.
If the lookup failed, we also purge the name cache
and attribute cache entries associated with h0.
The lack of atomcity between the RENAME and LOOKUP means
that even in the first case, we don't know for sure that
h0 was the file which was RENAMED. We could have had the
following scenario:
We opened A (and go back the handle h0).
Another client renamed A to be X.
That client renamed another file (with handle h2, say)
to be A.
We did our RENAME with resulted in h2 being called B.
After out RENAME but before our LOOKUP, come other
client renamed X (which has handle h0) to be B.
Our LOOKUP found that the handle corresponding to
A was h0, just as it would have been if our RENAME
had in fact renamed h0 from A to B.
The fact that we don't know what file our RENAME renamed,
doesn't matter. We know that h0 was RENAMED, if not by
us than by someone else and we also know the handle that
corresponds to the name B at a point after the RENAME,
and the associated attributes, and that is enough.
Now what the above won't do is update or purge the
attribute cache for h2, so accessing that file's attributes
somehow will get a stale ctime, but I don't see that as
a real problem. NFS's attribute caching has never been
coherent and is not in V4, either. Clients typically
update their own caches to reflect changes they themself
make, to avoid internal inconsistencies. But in this
case, even though the update of the ctime of h2 is done
by our own RENAME, I can't see that not updating that
ctime poses any problems that wouldn't have happened
anyway given multiple clients would have to be updating
ctimes with their own RENAME's.
> -----Original Message-----
> From: David Mazieres [mailto:dm@reeducation-labor.lcs.mit.edu]
> Sent: Monday, March 06, 2000 6:16 PM
> To: mre@eng.sun.com
> Cc: nfsv4-wg@sunroof.eng.sun.com
> Subject: Re: attributes of renamed file
>
>
> > Date: Mon, 6 Mar 2000 15:04:43 -0800 (PST)
> > From: Mike Eisler <mre@eng.sun.com>
> >
> > > It would be extremely useful if NFS4 servers could, after a RENAME
> > > operation, atomically return the file handle and
> change_info4 of the
> > > file actually being renamed. In many implementations the
> server will
> > > already have this information handy. The client could use this
> > > information to invalidate cached attributes without
> exposing itself to
> > > a race condition as it must currently do.
> >
> > Could you describe the race condition? The NFSv3 RENAME
> procedure didn't
> > include the equivalent of change_info4 on the target file,
> just from source and target directories?
> >
> > If the client has never cached any data on the file being
> renamed, why should
> > client and network be forced to bear the burden of
> extraneous information?
> >
> > If the information is handy, COMPOUND can be used to get it.
>
> Is a COMPOUND operation atomic? Suppose the client renames a file and
> then does a LOOKUP. If someone else gets in there and renames the
> file again, the client will end up thinking it renamed the wrong
> file.
>
> Suppose the client is caching the attributes for file A, and then
> RENAMEs file A but thinks it renamed file B (because of a non-atomic
> compound operation). If it doesn't flush the attributes for file A,
> it may return the wrong ctime in a stat system call.
>
> This can actually be pretty annoying in applications that rename a
> file then stat it. If they get a stale ctime, the next time they stat
> the file they will think it has changed, even though it hasn't changed
> since the rename.
>
> David
>
This archive was generated by hypermail 2.1.2 : 03/04/05-01:48:07 AM Z CST