Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
MIME-Version: 1.0
References: <50bd4b4d-3730-4048-fcce-6c79dfe70acf@garloff.de>
 <8957291b-ecd1-931e-5d0c-7ef20c401e5d@garloff.de> <F693AC98-DCB4-4086-AC19-EE1B71DB2551@netapp.com>
 <be851303-b1bb-7d8d-832e-a1a3db529662@garloff.de> <10d55787-7b97-8636-9426-73fdeda0a122@garloff.de>
 <6401c5e1-8f05-5644-9bea-207640a21b77@garloff.de> <CAN-5tyHC0m8nLgEi89EdKUo-kpEWsi-LUNHqAXc=gBzW+u52NA@mail.gmail.com>
 <53040065-a88b-1b60-3430-27d2acd761b7@garloff.de>
In-Reply-To: <53040065-a88b-1b60-3430-27d2acd761b7@garloff.de>
From:   Olga Kornievskaia <olga.kornievskaia@gmail.com>
Date:   Wed, 23 Feb 2022 12:49:30 -0500
Message-ID: <CAN-5tyHToHJKoqc38ybp9+DMVdUrapu+4u0i7YMpG86ZQFOw5w@mail.gmail.com>
Subject: Re: 6f283634 / 1976b2b3 breaks NFS (QNAP/Linux kNFSD)
To:     Kurt Garloff <kurt@garloff.de>
Cc:     "Kornievskaia, Olga" <Olga.Kornievskaia@netapp.com>,
        "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
        "Schumaker, Anna" <Anna.Schumaker@netapp.com>,
        Trond Myklebust <trond.myklebust@hammerspace.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Wed, Feb 23, 2022 at 12:31 PM Kurt Garloff <kurt@garloff.de> 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@garloff.de>
> Cologne, Germany