Subject: todo list for RFC3010

From: Spencer Shepler <[email-masked]>
Date: Tue, 22 May 2001 13:29:22 -0500

You will find pointers to the "todo" list and a version of RFC3010
that is the base document for our updates at:

http://www.nfsv4.org/rfc3010updates/index.html

---

From: "Kendrick M. Smith" <[email-masked]>
Date: Tue, 22 May 2001 15:20:48 -0400 (EDT)

Looks good to me.  Just curious: What is "Neil's proposal" for "fork/posix
issues with OPEN state"?

- k

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 22 May 2001 14:58:41 -0500

A bogus note that was left over.  I will remove it for now.

-- 

- Spencer -

---

From: "Matthew J. Zito" <[email-masked]>
Date: Tue, 22 May 2001 23:07:39 -0400

>http://www.nfsv4.org/rfc3010updates/index.html

"- If the server exporting a filesystem read-only, should 
OPEN(ACCESS_WRITE) fail with NFS4ERR_ROFS?  Or will the OPEN succeed 
and any WRITE()s will fail with NFS4ERR_ROFS."

I would suggest that open should fail on a read-only filesystem. 
That seems to be the way  the unixes I've looked at handle read-only 
filesystems.  Are there reasons for having it fail on write()?

As far as the close-retransmission issue goes, I think the server 
should maintain the close information for a certain amount of time. 
If there is a retransmission of the close() comamand after the 
original was received, it should return an error.  The only downside 
to doing this is the server has to keep track of recently closed 
files, but I think that's preferable to having an nfs server simply 
return OKs regardless of whether or not it knows anything about that 
request.

Thoughts?

Thanks,
Matt

-- 
Matthew J. Zito
Systems Engineer
Register.com, Inc., 11th Floor, 575 8th Avenue, New York, NY 10018
Ph: 212-798-9205
PGP Key Fingerprint: 4E AC E1 0B BE DD 7D BC  D2 06 B2 B0 BF 55 68 99

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 23 May 2001 18:09:37 -0500

> filesystems.  Are there reasons for having it fail on write()?

Failing on open() will be a change in behavior from the way NFSv2/v3
implementations deal with this.  Without OPEN, v2/v3 have no way to
determine if the file is read-only.  So failing the OPEN() will be a
change in behavior.  Is it a reasonable change?  I think so but as has
been pointed out in other threads these types of 'reasonable' changes
start to add up such that NFSv4 will behave enough differently from
v2/v3 as to "bother" the end user.

-- 

- Spencer -

---

From: "Matthew J. Zito" <[email-masked]>
Date: Wed, 23 May 2001 20:04:55 -0400

>v2/v3 as to "bother" the end user.

Are you sure nfsv2 provides this behavior?  From one of our linux 
servers mounting something as rw that is exported from a netapp filer 
ro:

[root@wwwb db]# strace touch testfile
<snip all kinds of irrelevant system calls>
open("/usr/share/locale/en_US/LC_CTYPE", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=10428, ...}) = 0
mmap(0, 10428, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40112000
close(3)                                = 0
stat("testfile", 0xbffffc20)            = -1 ENOENT (No such file or directory)
open("testfile", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = -1 
EACCES (Permission denied)

Is there something else that is making this happen?  I verified that 
the linux box is under the impression its mounted read-write.

But. even if there are implementations that fail on write() (or 
there's something bizarre going on here), failing on open() is (to my 
mind) more correct than failing on a write - you're opening with the 
intention to write, so if you're not allowed to write, it should 
notify you then, not at the first write attempt.

Thanks,
Matt

---

From: "Kendrick M. Smith" <[email-masked]>
Date: Wed, 23 May 2001 20:16:08 -0400 (EDT)

> notify you then, not at the first write attempt.

In fact, here's an example of something which should work in NFSv2/v3, but
doesn't, because permissions are checked on read()/write(), not on open():
 - open a file
 - while holding it open, chmod(000, ...) the file
 - try to read data from the file
There is even a Connectathon test for this, which will fail under
NFSv2/v3, but happily our Linux NFSv4 client and server can pass it,
since we check permissions only at OPEN (to be honest, we'd always
taken it for granted that permissions should be checked at OPEN in
NFSv4, rather than at READ/WRITE as in v2/v3!).

- k

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 23 May 2001 19:25:41 -0500

> the linux box is under the impression its mounted read-write.

Well, in this particular instance, the file doesn't exist and the
open() is attempting to create it.  This is failing with EACCES as
expected.

> notify you then, not at the first write attempt.

We have two votes for fail on open() of a read-only filesystem and I
agree that it should fail on open().  

The item was in the issues list to ensure the rfc was clear about what
was expected.

-- 

- Spencer -

---

From: Brent <[email-masked]>
Date: Wed, 23 May 2001 18:03:10 -0700

> v2/v3 as to "bother" the end user.

NFS v3 clients can use the ACCESS call to figure out whether
they have write access. This can be used at open() time to
return an error.

NFSv4 clients can use ACCESS too...

	Brent

---

From: "Sergey Klyushin" <[email-masked]>
Date: Thu, 24 May 2001 02:37:48 -0400

> -----Original Message-----
    > From: Spencer Shepler [mailto:[email-masked]]
    > Sent: Wednesday, May 23, 2001 8:26 PM
    > To: [email-masked]
    > Subject: Re: todo list for RFC3010
    >
    >
Count me also to fail on open()

Sergey