> On May 5, 2022, at 12:38 PM, Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote: > > > >> On May 5, 2022, at 1:31 AM, andreas-nagy@xxxxxxxxxxx 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@xxxxxxxxxx <crispyduck@xxxxxxxxxx> >> Gesendet: Mittwoch, 27. April 2022 08:08 >> An: Rick Macklem <rmacklem@xxxxxxxxxxx>; J. Bruce Fields <bfields@xxxxxxxxxxxx>; linux-nfs@xxxxxxxxxxxxxxx <linux-nfs@xxxxxxxxxxxxxxx> >> Cc: Chuck Lever III <chuck.lever@xxxxxxxxxx> >> 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@xxxxxxxxxxx> >> Gesendet: Sonntag, 24. April 2022 22:39 >> An: J. Bruce Fields <bfields@xxxxxxxxxxxx> >> Cc: crispyduck@xxxxxxxxxx <crispyduck@xxxxxxxxxx>; Chuck Lever III <chuck.lever@xxxxxxxxxx>; Linux NFS Mailing List <linux-nfs@xxxxxxxxxxxxxxx> >> Betreff: Re: Problems with NFS4.1 on ESXi >> >> Rick Macklem <rmacklem@xxxxxxxxxxx> 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
