From: "J. Bruce Fields" <bfields@fieldses.org>
To: dai.ngo@oracle.com
Cc: chuck.lever@oracle.com, jlayton@redhat.com,
viro@zeniv.linux.org.uk, linux-nfs@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH RFC v21 0/7] NFSD: Initial implementation of NFSv4 Courteous Server
Date: Mon, 25 Apr 2022 15:19:15 -0400 [thread overview]
Message-ID: <20220425191915.GF24825@fieldses.org> (raw)
In-Reply-To: <ed6893fa-fbb1-36a7-226a-4436edd34644@oracle.com>
On Mon, Apr 25, 2022 at 11:16:54AM -0700, dai.ngo@oracle.com wrote:
>
> On 4/25/22 10:53 AM, J. Bruce Fields wrote:
> >I'm getting a few new pynfs failures after applying these. I haven't
> >tried to investigage what's happening.
> >
> >--b.
> >
> >**************************************************
> >RENEW3 st_renew.testExpired : FAILURE
> > nfs4lib.BadCompoundRes: Opening file b'RENEW3-1':
> > operation OP_OPEN should return NFS4_OK, instead got
> > NFS4ERR_DELAY
> >LKU10 st_locku.testTimedoutUnlock : FAILURE
> > nfs4lib.BadCompoundRes: Opening file b'LKU10-1':
> > operation OP_OPEN should return NFS4_OK, instead got
> > NFS4ERR_DELAY
> >CLOSE9 st_close.testTimedoutClose2 : FAILURE
> > nfs4lib.BadCompoundRes: Opening file b'CLOSE9-1':
> > operation OP_OPEN should return NFS4_OK, instead got
> > NFS4ERR_DELAY
> >CLOSE8 st_close.testTimedoutClose1 : FAILURE
> > nfs4lib.BadCompoundRes: Opening file b'CLOSE8-1':
> > operation OP_OPEN should return NFS4_OK, instead got
> > NFS4ERR_DELAY
>
> with this patches, OPEN (v4.0 and v4.1) might have to handle NFS4ERR_DELAY
> if there is a reservation conflict. I had to modify open_confirm (v4.0) and
> open_create_file (v4.1) to handle the NFS4ERR_DELAY error.
Looking at your patch 2....
OK, my suggestion was: "in the case of a conflict, call
try_to_expire_client and queue_work(), then modify e.g.
nfs4_get_vfs_file to flush_workqueue() and then retry after unlocking
fi_lock." You're returning DELAY instead of waiting for the workqueue.
After thinking on it a minute.... I like your way better. It's simpler.
Any client has to handle DELAY on OPEN, for the delegation-conflict
case. Maybe it's a little suboptimal, but so what, this is a very rare
case.
So, good thinking, let's stick with that idea. We'll just need to fix
up pynfs some time.
--b.
prev parent reply other threads:[~2022-04-25 19:19 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-23 18:44 [PATCH RFC v21 0/7] NFSD: Initial implementation of NFSv4 Courteous Server Dai Ngo
2022-04-23 18:44 ` [PATCH RFC v21 1/7] NFSD: add courteous server support for thread with only delegation Dai Ngo
2022-04-25 18:51 ` J. Bruce Fields
2022-04-25 19:42 ` dai.ngo
2022-04-25 20:40 ` J. Bruce Fields
2022-04-25 21:35 ` dai.ngo
2022-04-25 21:48 ` J. Bruce Fields
2022-04-25 22:24 ` dai.ngo
2022-04-25 23:17 ` J. Bruce Fields
2022-04-23 18:44 ` [PATCH RFC v21 2/7] NFSD: add support for share reservation conflict to courteous server Dai Ngo
2022-04-25 13:15 ` Chuck Lever III
2022-04-25 15:08 ` dai.ngo
2022-04-23 18:44 ` [PATCH RFC v21 3/7] NFSD: move create/destroy of laundry_wq to init_nfsd and exit_nfsd Dai Ngo
2022-04-25 15:27 ` dai.ngo
2022-04-25 19:35 ` J. Bruce Fields
2022-04-25 19:46 ` dai.ngo
2022-04-23 18:44 ` [PATCH RFC v21 4/7] fs/lock: add helper locks_owner_has_blockers to check for blockers Dai Ngo
2022-04-23 18:44 ` [PATCH RFC v21 5/7] fs/lock: add 2 callbacks to lock_manager_operations to resolve conflict Dai Ngo
2022-04-23 18:44 ` [PATCH RFC v21 6/7] NFSD: add support for lock conflict to courteous server Dai Ngo
2022-04-23 18:44 ` [PATCH RFC v21 7/7] NFSD: Show state of courtesy client in client info Dai Ngo
2022-04-25 16:17 ` [PATCH RFC v21 0/7] NFSD: Initial implementation of NFSv4 Courteous Server J. Bruce Fields
2022-04-25 17:53 ` J. Bruce Fields
2022-04-25 18:16 ` dai.ngo
2022-04-25 19:19 ` J. Bruce Fields [this message]
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=20220425191915.GF24825@fieldses.org \
--to=bfields@fieldses.org \
--cc=chuck.lever@oracle.com \
--cc=dai.ngo@oracle.com \
--cc=jlayton@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).