linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rick Macklem <rmacklem@uoguelph.ca>
To: Chuck Lever III <chuck.lever@oracle.com>
Cc: Bruce Fields <bfields@fieldses.org>,
	"crispyduck@outlook.at" <crispyduck@outlook.at>,
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: Problems with NFS4.1 on ESXi
Date: Fri, 22 Apr 2022 22:58:10 +0000	[thread overview]
Message-ID: <YT2PR01MB97303F9E6AE14BE4D489F9BEDDF79@YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <A22B7B39-1FEA-4FFF-84D4-0FCBE42B590B@oracle.com>

Chuck Lever III <chuck.lever@oracle.com> wrote:
> On Apr 21, 2022, at 7:52 PM, Rick Macklem <rmacklem@uoguelph.ca> wrote:
[stuff snipped]
> > I took a look at crispyduck's packet trace and here's what I saw:
> > Packet#
> > 48 Lookup of test-ovf.vmx
> > 49 NFS_OK FH is 0x7c9ce14b (the hash)
> > ...
> > 51 Open Claim_FH fo 0x7c9ce14b
> > 52 NFS_OK Open Stateid 0x35be
> > ...
> > 138 Rename test-ovf.vmx~ to test-ovf.vmx
> > 139 NFS_OK
> > ...
> > 141 Close with PutFH 0x7c9ce14b
> > 142 NFS4ERR_STALE for the PutFH
> >
> > So, it seems that the Rename will delete the file (names another file to the
> > same name "test-ovf.vmx".  Then the subsequent Close's PutFH fails,
> > because the file for the FH has been deleted.
>
> So, Rick, Andreas: does this sequence of operations work without
> error against a FreeBSD NFS server?
Good question. For a UFS exported file system I am pretty sure the server
would reply with ESTALE to the PutFH, just like Linux.

For ZFS, I am not so sure. The translation from FH to vnode is done by
a file system specific method. If that fails, ESTALE is replied. If ZFS can still
generate a vnode for a file when it has been removed (or while the remove
is in progress, as it might be in this case), then no error would be replied.
(The NFSv4 Close operation doesn't actually use the vnode, it only uses
 the StateID and FH to find/close the NFSv4 open state.)

The FreeBSD server never sets OPEN_RESULT_PRESERVE_UNLINKED
in the Open reply and it is not intended to retain the file until Close.

Maybe Andreas will find that out, if he can do more testing against a
FreeBSD server?

I am also not sure if the ESTALE replies are an issue for the ESXi client, since
they happen multiple times in the packet trace and only generate a warning
message in the client's log.

I did not see anything else in the trace that would indicate why the client
might be failing, however it did look like some packets were missing from
the trace.

rick

--
Chuck Lever





  parent reply	other threads:[~2022-04-22 23:20 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <AM9P191MB1665484E1EFD2088D22C2E2F8EF59@AM9P191MB1665.EURP191.PROD.OUTLOOK.COM>
2022-04-21  4:55 ` Problems with NFS4.1 on ESXi Andreas Nagy
2022-04-21 14:58   ` Chuck Lever III
2022-04-21 15:30     ` AW: " crispyduck
2022-04-21 16:40       ` J. Bruce Fields
     [not found]         ` <AM9P191MB16654F5B7541CD1E489D75608EF49@AM9P191MB1665.EURP191.PROD.OUTLOOK.COM>
2022-04-21 18:41           ` crispyduck
2022-04-21 18:54         ` J. Bruce Fields
2022-04-21 23:52           ` Rick Macklem
2022-04-21 23:58             ` Rick Macklem
2022-04-22 14:29             ` Chuck Lever III
2022-04-22 14:59               ` AW: " crispyduck
2022-04-22 15:02                 ` Chuck Lever III
2022-04-22 22:58               ` Rick Macklem [this message]
2022-04-22 15:15             ` J. Bruce Fields
2022-04-22 18:43               ` AW: " crispyduck
2022-04-22 23:03               ` Rick Macklem
2022-04-24 15:07                 ` J. Bruce Fields
2022-04-24 20:36                   ` Rick Macklem
2022-04-24 20:39                     ` Rick Macklem
2022-04-25  9:00                       ` AW: " crispyduck
2022-04-27  6:08                         ` crispyduck
2022-05-05  5:31                           ` andreas-nagy
2022-05-05 14:19                             ` Rick Macklem
2022-05-05 16:38                             ` Chuck Lever III
2022-05-07  1:53                               ` Chuck Lever III
2022-04-22 14:23           ` Olga Kornievskaia

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=YT2PR01MB97303F9E6AE14BE4D489F9BEDDF79@YT2PR01MB9730.CANPRD01.PROD.OUTLOOK.COM \
    --to=rmacklem@uoguelph.ca \
    --cc=bfields@fieldses.org \
    --cc=chuck.lever@oracle.com \
    --cc=crispyduck@outlook.at \
    --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 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).