From: cel@kernel.org
To: <linux-nfs@vger.kernel.org>
Cc: Chuck Lever <chuck.lever@oracle.com>
Subject: [RFC PATCH 0/2] NFSD: expand the implementation of OFFLOAD_STATUS
Date: Tue, 30 Apr 2024 16:05:09 -0400 [thread overview]
Message-ID: <20240430200519.6253-1-cel@kernel.org> (raw)
From: Chuck Lever <chuck.lever@oracle.com>
I'm looking at RFC 7862 to try to understand what the various
OFFLOAD_STATUS responses mean.
> 15.9.3. DESCRIPTION
>
> OFFLOAD_STATUS can be used by the client to query the progress of an
> asynchronous operation, which is identified by both CURRENT_FH and
> the osa_stateid. If this operation is successful, the number of
> bytes processed is returned to the client in the osr_count field.
NFSD returns only the byte count today.
> If the optional osr_complete field is present, the asynchronous
> operation has completed. In this case, the status value indicates
> the result of the asynchronous operation.
NFSD currently never returns the status code -- NFSD's response XDR
encoder always stuffs "zero" in the array count for the osr_complete
array. IMO, zero is OK, but only for the “COPY is still running”
case.
Once the async COPY has completed, a subsequent OFFLOAD_STATUS
should show that the COPY succeeded (or failed), until the server
receives the client’s CB_OFFLOAD reply, or until the client’s lease
expires.
For the "COPY has completed successfully" case, the above text
suggests that OFFLOAD_STATUS returns NFS4_OK, and needs to return a
proper status code in the osr_complete array: Probably NFS4_OK.
A "COPY has completed but failed" status can be reported by
OFFLOAD_STATUS returning NFS4_OK and setting the osr_complete field
to the failing COPY status code.
The two patches here change NFSD in that direction.
Chuck Lever (2):
NFSD: Record status of async copy operation in struct nfsd4_copy
NFSD: Add COPY status code to OFFLOAD_STATUS response
fs/nfsd/nfs4proc.c | 31 ++++++++++++++++++-------------
fs/nfsd/nfs4xdr.c | 7 ++++++-
fs/nfsd/xdr4.h | 5 ++++-
3 files changed, 28 insertions(+), 15 deletions(-)
base-commit: 06cd86b25b980a58e5584e9cd38c080467b24c25
--
2.44.0
next reply other threads:[~2024-04-30 20:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-30 20:05 cel [this message]
2024-04-30 20:05 ` [RFC PATCH 1/2] NFSD: Record status of async copy operation in struct nfsd4_copy cel
2024-04-30 20:05 ` [RFC PATCH 2/2] NFSD: Add COPY status code to OFFLOAD_STATUS response cel
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=20240430200519.6253-1-cel@kernel.org \
--to=cel@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=linux-nfs@vger.kernel.org \
/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.