From: Chuck Lever III <chuck.lever@oracle.com>
To: "andreas-nagy@outlook.com" <andreas-nagy@outlook.com>
Cc: "crispyduck@outlook.at" <crispyduck@outlook.at>,
Rick Macklem <rmacklem@uoguelph.ca>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: Problems with NFS4.1 on ESXi
Date: Sat, 7 May 2022 01:53:09 +0000 [thread overview]
Message-ID: <91B9C47D-586F-4352-8484-730C8362CD65@oracle.com> (raw)
In-Reply-To: <D267ABA2-A071-4406-A218-919DC7414DCF@oracle.com>
> On May 5, 2022, at 12:38 PM, Chuck Lever III <chuck.lever@oracle.com> wrote:
>
>
>
>> On May 5, 2022, at 1:31 AM, andreas-nagy@outlook.com wrote:
>>
>> Hi,
>>
>> was someone able to check the NFS3 vs NFS4.1 traces (https://easyupload.io/7bt624)? I was due to quarantine I was so far not able to test it against FreeBSD.
>
> I don't see anything new in the NFSv4.1 trace from the above package.
>
> The NFSv3 trace doesn't have any remarkable failures. But since the
> NFSv3 protocol doesn't have a CLOSE operation, it shouldn't be
> surprising that there is no failure there.
>
> Seeing the FreeBSD behavior is the next step. I have a little time
> today to audit code to see if there's anything obvious there. I will
> have to stick with ext4 since I don't have any ZFS code here and you
> said you were able to reproduce on an ext4 export.
I looked for ways in which a cached open might be unintentionally
closed by a RENAME. Code audit revealed two potential candidates:
commit 7775ec57f4c7 ("nfsd: close cached files prior to a REMOVE
or RENAME that would replace target") and commit 7f84b488f9ad
("nfsd: close cached files prior to a REMOVE or RENAME that would
replace target") (Yes, they have the same short description).
I need to explore these two patches and possibly build a pynfs
test that does OPEN(CREATE)/RENAME/CLOSE. I'm away from the office
for another few days to it will take a while.
Until then, I guess reproducing with FreeBSD isn't needed.
>> Would it maybe make any difference updating the Ubuntu based Linux kernel from 5.13 to 5.15?
>
> I don't yet know enough about the issue to say whether it might
> have been addressed between .13 and .15. So far the issue is not
> familiar from recent code changes.
>
>
>> Br
>> Andreas
>>
>>
>>
>>
>> Von: crispyduck@outlook.at <crispyduck@outlook.at>
>> Gesendet: Mittwoch, 27. April 2022 08:08
>> An: Rick Macklem <rmacklem@uoguelph.ca>; J. Bruce Fields <bfields@fieldses.org>; linux-nfs@vger.kernel.org <linux-nfs@vger.kernel.org>
>> Cc: Chuck Lever III <chuck.lever@oracle.com>
>> Betreff: AW: Problems with NFS4.1 on ESXi
>>
>> I tried again to reproduce the "sometimes working" case, but at the moment it always fails. No Idea why it in the past sometimes worked.
>> Why are this much lookups in the trace? Dont see this on other NFS clients.
>>
>> The traces with nfs3 where it works and nfs41 where it always fails are here:
>> https://easyupload.io/7bt624
>>
>> Both from mount till start of vm import (testvm).
>>
>> exportfs -v:
>> /zfstank/sto1/ds110
>> <world>(async,wdelay,hide,crossmnt,no_subtree_check,fsid=74345722,mountpoint,sec=sys,rw,secure,no_root_squash,no_all_squash)
>>
>>
>> I hope I can also do some tests against a FreeBSD server end of the week.
>>
>> regards,
>> Andreas
>>
>>
>>
>> Von: Rick Macklem <rmacklem@uoguelph.ca>
>> Gesendet: Sonntag, 24. April 2022 22:39
>> An: J. Bruce Fields <bfields@fieldses.org>
>> Cc: crispyduck@outlook.at <crispyduck@outlook.at>; Chuck Lever III <chuck.lever@oracle.com>; Linux NFS Mailing List <linux-nfs@vger.kernel.org>
>> Betreff: Re: Problems with NFS4.1 on ESXi
>>
>> Rick Macklem <rmacklem@uoguelph.ca> wrote:
>> [stuff snipped]
>>> In FreeBSD, it actually hangs onto the parent's FH (verbatim), but mostly
>>> so it can do Open/Claim_NULLs for it. There is nothing in FreeBSD that
>>> tries to subvert FH guessing.
>> Oops, this is client side, not server side. (I forgot which hat I was wearing;-)
>> The FreeBSD server does not keep track of parents.
>>
>> rick
>>
>> --b.
>
> --
> Chuck Lever
--
Chuck Lever
next prev parent reply other threads:[~2022-05-07 1:53 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
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 [this message]
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=91B9C47D-586F-4352-8484-730C8362CD65@oracle.com \
--to=chuck.lever@oracle.com \
--cc=andreas-nagy@outlook.com \
--cc=crispyduck@outlook.at \
--cc=linux-nfs@vger.kernel.org \
--cc=rmacklem@uoguelph.ca \
/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).