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.
