Hi, Am 24. Februar 2022 14:42:41 MEZ schrieb Kurt Garloff <kurt@xxxxxxxxxx>: >Hi Olga, >[...] > >I see a number of possibilities to resolve this: >(0) We pretend it's not a problem that's serious enough to take > action (and ensure that we do document this new option well). >(1) We revert the patch that does FS_LOCATIONS discovery. > Assuming that FS_LOCATIONS does provide a useful feature, this > would not be our preferred solution, I guess ... >(2) We prevent NFS v4.1 servers to use FS_LOCATIONS (like my patch > implements) and additionally allow for the opt-out with > notrunkdiscovery mount option. This fixes the known regression > with Qnap knfsd (without requiring user intervention) and still > allows for FS_LOCATIONS to be useful with NFSv4.2 servers that > support this. The disadvantage is that we won't use the feature > on NFSv4.1 servers which might support this feature perfectly > (and there's no opt-in possibility). And the risk is that there > might be NFSv4.2 servers out there that also misreport > FS_LOCATIONS support and still need manual intervention (which > at least is possible with notrunkdiscovery). >(3) We make this feature an opt-in thing and require users to > pass trunkdiscovery to take advantage of the feature. > This has zero risk of breakage (unless we screw up the patch), > but always requires user intervention to take advantage of > the FS_LOCATIONS feature. >(4) Identify a way to recover from the mount with FS_LOCATIONS > against the broken server, so instead of hanging we do just > turn this off if we find it not to work. Disadavantage is that > this adds complexity and might stall the mounting for a while > until the recovery worked. The complexity bears the risk for > us screwing up. > >I personally find solutions 2 -- 4 acceptable. > >If the experts see (4) as simple enough, it might be worth a try. >Otherwise (2) or (3) would seem the way to go from my perspective. Any thought ls? Thanks, -- Kurt Garloff <kurt@xxxxxxxxxx>, Cologne, Germany (Sent from Mobile with K9.)
