From: Noveck, Dave (dave.noveck@netapp.com)
Date: 04/10/00-04:56:46 PM Z
Message-ID: <F6C5585BF0CED311B58D009027C2299C47C07D@tahoe.corp.netapp.com>
From: "Noveck, Dave" <dave.noveck@netapp.com>
Subject: RE: Upcoming draft-07 for NFSv4
Date: Mon, 10 Apr 2000 14:56:46 -0700
> BTW, Vern's comments on why GETFH was needed or not, reminds me that
> it is an absolute disaster if the client fails include an GETFH after
> an OPEN. The reason is that even without the GETFH, the state
> established by
> OPEN remains established each time the client does an operation causes
> all leases to be renewed, including the one for the file it has to no
> file handle for. At minimum, section 14.2.15. "Operation 18:
> OPEN - Open a Regular File" should discuss this, but I'm
> wondering if a COMPOUND that
> has an OPEN without an corresponding GETFH should cause an
> implicit CLOSE
> to be done. This could actually be useful for COMPOUNDs like:
>
> putrootfh, open "a" "b" "c" ; read 0 512 ;
>
This could get really complicated, given the possiblities
of multiple opens for the same file (open upgrade/downgrade
logic), possibly under different names.
Consider a case in which a/b/c and a/b/x both
designate the same file.
If I open a/b/c on one request (with a GETFH) and
then open a/b/x (which is a hard link to a/b/c) in a
COMPOUND where it is not followed by a GETFH, then
the OPEN is an open-upgrade but you definitely don't
want an implicit close that undoes the work of the
open on a/b/c.
You could make a special rule about an open which
turns out to be an upgrade so that instead of doing
a close, the server has to do an open-downgrade but
I think this can get pretty ugly for the server
given the possibility that the open for a/b/c
(the one that does have the GETFH) might come in
later and be executed interleaved with the other
compound.
Also, you could have this COMPOUND:
OPEN "a" "b" "c"
READ
OPEN "a" "b" "x"
GETFH
Now you don't want a CLOSE, you want an OPEN_DOWNGRADE
operation, even though the OPEN without GETFH isn't an
upgrade.
I like the idea of having OPEN return the fh. If we
don't do that, client should be strongly warned that
they had better do a GETFH after each OPEN (and save
the results). Servers should be warned not to do
anti-social things like returning NFS4ERR_RESOURCE
on the GETFH following an OPEN.
This archive was generated by hypermail 2.1.2 : 03/04/05-01:48:10 AM Z CST