All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mi Jinlong <mijinlong@cn.fujitsu.com>
To: trond.myklebust@fys.uio.no
Cc: NFSv3 community <linux-nfs@vger.kernel.org>,
	mingo@elte.hu, bfields@fieldses.org
Subject: [RFC] When locking an inexistent file, NFSv3 and NFSv4 get different result.
Date: Tue, 20 Oct 2009 17:06:23 +0800	[thread overview]
Message-ID: <4ADD7D8F.1040700@cn.fujitsu.com> (raw)


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


             reply	other threads:[~2009-10-20  9:05 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-20  9:06 Mi Jinlong [this message]
2009-10-20 19:47 ` [RFC] When locking an inexistent file, NFSv3 and NFSv4 get different result Peter Staubach
2009-10-20 22:00 ` Trond Myklebust

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4ADD7D8F.1040700@cn.fujitsu.com \
    --to=mijinlong@cn.fujitsu.com \
    --cc=bfields@fieldses.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=trond.myklebust@fys.uio.no \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.