On Wed, Feb 23, 2022 at 12:31 PM Kurt Garloff <kurt@xxxxxxxxxx> wrote: > > Hi Olga, > > thanks for coming back! > > On 23.02.22 15:22, Olga Kornievskaia wrote: > > Hi Kurt, > > I apologize for the late response. I have looked at the network trace. > > The problem stems from the broken server that claims to support > > fs_locations but then decides to never reply to the query. > > > > I can implement a mount option to say fs_locquery=off to handle mounts > > against the broken servers? > > I have posted a patch where you can mount with "notrunkdiscovery" and that should fix the problem with the Qnap server? > > However I would like to ask if the better path forward isn't to update > > to the knfsd where the problem is fixed? > > Well, I have ran self-compiled kernels on Qnap appliances before (to > work around Qnap's ext4 breakage when doing the case-independent > name lookup), but it was a painful and cumbersome process and I don't > want to repeat it. Appliances are not meant to use with custom > kernels. > Even if I do: This does not help many many other users ... Unless we > convince Qnap to provide patches for old appliances, we'll experience > breakage. > > On my end, I have applied the attached patch, restricting the use > of FS_LOCATIONS to servers that advertize NFS v4.2 or later. > > In the patch, you'll also see clearing the bit before it gets set. > This was spotted by seth, see > https://bbs.archlinux.org/viewtopic.php?pid=2023983#p2023983 > In latest upstream kernels you'd also need to clear > NFS_CAP_CASE_PRESERVING | NFS_CAP_CASE_INSENSITIVE > so I wonder whether we should not just nullify the caps > bit field prior to testing and selectively setting flags. > > With this patch, I can mount NFS volumes from Qnap knfsd > again without any special workarounds (such as nfsver=3 or the > to-be-implemented setting that you suggest). I have no idea > whether or not we leave a lot features behind by restricting > FS_LOCATIONS on the client side to servers >= NFS v4.2. > But certainly better than breaking in a -stable kernel update, > even if the server might be to blame. > > Best, > > -- > Kurt Garloff <kurt@xxxxxxxxxx> > Cologne, Germany
