* [RFC] When locking an inexistent file, NFSv3 and NFSv4 get different result.
@ 2009-10-20 9:06 Mi Jinlong
2009-10-20 19:47 ` Peter Staubach
2009-10-20 22:00 ` Trond Myklebust
0 siblings, 2 replies; 3+ messages in thread
From: Mi Jinlong @ 2009-10-20 9:06 UTC (permalink / raw)
To: trond.myklebust; +Cc: NFSv3 community, mingo, bfields
When locking an inexistent file, NFSv3 and NFSv4 get different result.
A: Test procedure=EF=BC=9A
Client Server
---------------+----------------
step1: open file |
step2: | delete file
step3: lock file |
step4: close file |
V
On NFSv3: lock file fail, and return ESTALE at step3.
On NFSv4: lock file success, and return OK at step3.
B: Reason:
NFSv4 server open file when client open the file at step1.
so it can lock file success at step3.
NFSv3 server don't open file when client open the file at step1,
but open file at step3, so lock fail caused by open file fail.
C: Suggestion:
I suggest modifying the NFSv3 to accordding with NFSv4. As followed:
1. Add two NLMPROCs for nlm.
NLMPROC_OPEN: client sent it to server, and server open file
NLMPROC_CLOSE: client sent it to server, and server close file
2.=20
If use NLM, client send NLMPROC_OPEN request to server when client=
open file,
and send NLMPROC_CLOSE request when client close file.
client server
| nfs.lookup request |
Open |----------------------->|
| nfs.lookup reply |
|<-----------------------|
| |
| NLMPROC_OPEN request |
|----------------------->| open file and add it to nlm_fi=
les list
| NLMPROC_OPEN reply | =20
|<-----------------------|
| |
Lock | NMLPROC_LOCK request |
|----------------------->| use the file opened before=20
| NMLPROC_LOCK reply |
|<-----------------------|
| |
Close | NMLPROC_CLOSE request |
|----------------------->| remove the file from nlm_files=
list
| NMLPROC_CLOSE reply |
|<-----------------------|
V V
--=20
Regards
Mi Jinlong
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [RFC] When locking an inexistent file, NFSv3 and NFSv4 get different result.
2009-10-20 9:06 [RFC] When locking an inexistent file, NFSv3 and NFSv4 get different result Mi Jinlong
@ 2009-10-20 19:47 ` Peter Staubach
2009-10-20 22:00 ` Trond Myklebust
1 sibling, 0 replies; 3+ messages in thread
From: Peter Staubach @ 2009-10-20 19:47 UTC (permalink / raw)
To: Mi Jinlong; +Cc: trond.myklebust, NFSv3 community, mingo, bfields
Mi Jinlong wrote:
> When locking an inexistent file, NFSv3 and NFSv4 get different result=
=2E
>=20
> A: Test procedure=EF=BC=9A
>=20
> Client Server
> ---------------+----------------
> step1: open file |
> step2: | delete file
> step3: lock file |
> step4: close file |
> V
>=20
> On NFSv3: lock file fail, and return ESTALE at step3.
> On NFSv4: lock file success, and return OK at step3.
>=20
> B: Reason:
>=20
> NFSv4 server open file when client open the file at step1.
> so it can lock file success at step3.
> NFSv3 server don't open file when client open the file at step1,
> but open file at step3, so lock fail caused by open file fai=
l.
>=20
> C: Suggestion:
>=20
> I suggest modifying the NFSv3 to accordding with NFSv4. As followe=
d:
>=20
> 1. Add two NLMPROCs for nlm.
>=20
> NLMPROC_OPEN: client sent it to server, and server open file
> NLMPROC_CLOSE: client sent it to server, and server close file
>=20
Modifying the NLM protocol is pretty much a non-starter.
While not well documented, it is implemented already by
most implementations. Most of those implementations have
already placed their NFSv2 and NFSv3 implementations on
support only and the only development occuring is on the
NFSv4 implementation.
This is another case of pretty much just how NFS has worked
for 20+ years now. Most people have learned how to deal
with it and thus, fixing it, is more work than it is worth.
Also, if the scenario below was the only one, it might be
slightly worth considering. However, what happens if the
client never sends an NLMPROC_CLOSE? The file can never
be really deleted. NFSv4 has explicit support for a
situation like this, so would handle it.
ps
> 2.=20
> If use NLM, client send NLMPROC_OPEN request to server when clie=
nt open file,
> and send NLMPROC_CLOSE request when client close file.
>=20
> client server
> | nfs.lookup request |
> Open |----------------------->|
> | nfs.lookup reply |
> |<-----------------------|
> | |
> | NLMPROC_OPEN request |
> |----------------------->| open file and add it to nlm_=
files list
> | NLMPROC_OPEN reply | =20
> |<-----------------------|
> | |
> Lock | NMLPROC_LOCK request |
> |----------------------->| use the file opened before=20
> | NMLPROC_LOCK reply |
> |<-----------------------|
> | |
> Close | NMLPROC_CLOSE request |
> |----------------------->| remove the file from nlm_fil=
es list
> | NMLPROC_CLOSE reply |
> |<-----------------------|
> V V
>=20
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [RFC] When locking an inexistent file, NFSv3 and NFSv4 get different result.
2009-10-20 9:06 [RFC] When locking an inexistent file, NFSv3 and NFSv4 get different result Mi Jinlong
2009-10-20 19:47 ` Peter Staubach
@ 2009-10-20 22:00 ` Trond Myklebust
1 sibling, 0 replies; 3+ messages in thread
From: Trond Myklebust @ 2009-10-20 22:00 UTC (permalink / raw)
To: Mi Jinlong; +Cc: NFSv3 community, mingo, bfields
On Tue, 2009-10-20 at 17:06 +0800, Mi Jinlong wrote:
> When locking an inexistent file, NFSv3 and NFSv4 get different result=
=2E
>=20
> A: Test procedure=EF=BC=9A
>=20
> Client Server
> ---------------+----------------
> step1: open file |
> step2: | delete file
> step3: lock file |
> step4: close file |
> V
>=20
> On NFSv3: lock file fail, and return ESTALE at step3.
> On NFSv4: lock file success, and return OK at step3.
>=20
> B: Reason:
>=20
> NFSv4 server open file when client open the file at step1.
> so it can lock file success at step3.
> NFSv3 server don't open file when client open the file at step1,
> but open file at step3, so lock fail caused by open file fai=
l.
>=20
> C: Suggestion:
>=20
> I suggest modifying the NFSv3 to accordding with NFSv4. As followe=
d:
>=20
> 1. Add two NLMPROCs for nlm.
>=20
> NLMPROC_OPEN: client sent it to server, and server open file
> NLMPROC_CLOSE: client sent it to server, and server close file
>=20
> 2.=20
> If use NLM, client send NLMPROC_OPEN request to server when clie=
nt open file,
> and send NLMPROC_CLOSE request when client close file.
>=20
> client server
> | nfs.lookup request |
> Open |----------------------->|
> | nfs.lookup reply |
> |<-----------------------|
> | |
> | NLMPROC_OPEN request |
> |----------------------->| open file and add it to nlm_=
files list
> | NLMPROC_OPEN reply | =20
> |<-----------------------|
> | |
> Lock | NMLPROC_LOCK request |
> |----------------------->| use the file opened before=20
> | NMLPROC_LOCK reply |
> |<-----------------------|
> | |
> Close | NMLPROC_CLOSE request |
> |----------------------->| remove the file from nlm_fil=
es list
> | NMLPROC_CLOSE reply |
> |<-----------------------|
> V V
>=20
Huh??? There are no NLMPROC_OPEN/NLMPROC_CLOSE for use by NFSv3 in any
existing protocol.
If you are talking about modifying the _protocol_ to add new state, the=
n
the answer is that we already did that, and the result is called
NFSv4...
Trond
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-10-20 22:00 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-10-20 9:06 [RFC] When locking an inexistent file, NFSv3 and NFSv4 get different result Mi Jinlong
2009-10-20 19:47 ` Peter Staubach
2009-10-20 22:00 ` Trond Myklebust
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.