Date: Mon, 2 Dec 2024 15:23:08 -0500 From: J David <j.david.lists@gmail.com> To: Rick Macklem <rick.macklem@gmail.com> Cc: FreeBSD FS <freebsd-fs@freebsd.org> Subject: Re: NFS 4.2 "RPC struct is bad" revisited (with much more detail) Message-ID: <CABXB=RRH%2BxgM6M469R5F5qiap93f1cJdbQroqf3FWhHHeKzw4Q@mail.gmail.com> In-Reply-To: <CAM5tNy44wh9h0gvi7ySonkkA3CZQN72a-paSK4Lk_BSsB2M8XA@mail.gmail.com> References: <CABXB=RT7Sb76bPZg3k%2BM5wt3q1Ern56zmzyviN0_zdj27pqQLw@mail.gmail.com> <CAM5tNy44wh9h0gvi7ySonkkA3CZQN72a-paSK4Lk_BSsB2M8XA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Dec 1, 2024 at 8:03=E2=80=AFPM Rick Macklem <rick.macklem@gmail.com= > wrote: > Well, this indicates the Debian server is broken. A bitmap and associated > attribute values are required for a GETATTR reply of NFS4_OK. > This clearly says they are not there. > > That would result in the client saying the RPC is bad. Even if the response to that isn't "A problem that occurs only with FreeBSD clients is a FreeBSD client problem; it shouldn't do the thing that causes that to happen," it could take quite some time for any change made by the linux-nfs crowd to filter through to reaching a production Debian release. Is there a reasonable way to apply Postel's law here and modify the client to warn on but accept this behavior rather than erroring out in a way that renders the file structure unusable indefinitely? Even refusing to cache this response if it is unusable would probably be an improvement. Thanks!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CABXB=RRH%2BxgM6M469R5F5qiap93f1cJdbQroqf3FWhHHeKzw4Q>