Re: Problems with NFS4.1 on ESXi

[Chuck Lever III <chuck.lever@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