Re: Subtle NFS incompatibility with SunOS 4.1.1 on 68K

[David Brownlee <abs%absd.org@localhost>]

On Mon, 23 Mar 2020 at 21:53, Chris Hanson <cmhanson%eschatologist.net@localhost> wrote:
>
> On Mar 23, 2020, at 12:34 AM, Michael van Elst <mlelstv%serpens.de@localhost> wrote:
> >
> > cmhanson%eschatologist.net@localhost (Chris Hanson) writes:
> >
> >> So something is definitely going wrong in what the server is reporting under NFSv2 for a >2GB volume.
> >
> > NFSv2 uses signed 32bit integers and the code simply truncates larger numbers.
> >
> > There is no perfect solution since NFSv2 cannot handle larger filesytems or
> > files, but clamping the values to INT32_MAX should help. There are two
> > places that are relevant: filesystem data (size, free+avail blocks)
> > and file data (file length).
>
> I think I've found the spot in the code where this lives, this would be in nfsrv_statfs() sys/nfs/nfs_serv.c, correct? Where it sets sfp->sf_* to a bunch of txdr_unsigned() without clamping them?

There are probably more - I suspect
https://nxr.netbsd.org/xref/src/sys/nfs/nfs_subs.c#1697 is going to be
needed for file sizes.

> Do I have to rebuild the entire kernel to attempt a fix or can I just rebuild NFS somehow? (If the latter, is there a walkthrough somewhere?)

You'll need to rebuild the entire kernel - if you have a faster box
with disk space its usually easier to download the source onto that,
then

./build.sh -U -m MACHINE tools kernel=GENERIC

(where MACHINE is the output of "uname -p" from the target box)

after the first build you can just use the config and nbmake-MACHINE
from obj/tooldir.*/bin/ to rebuild the kernel

> > For files there is a danger. SunOS did fail syscalls for large files
> > and hid them from directory listings to prevent programs from using
> > clamped or otherwise truncated size values. For simple things, like
> > writing a logfile that grows beyond 2GB that's maybe too strong.
> > On the other hand, Your SunOS client may not yet support large files,
> > so it would be a good thing.
>
> I'm not too worried about this personally, even if it's an issue generally. I don't expect to be working with files that large on an older NFSv2-only operating system, I don't think many others do either. It'd still be good to know for sure and have the bug logged, I'm sure, and also to fix eventually for correctness.

I think it would be good to fix - if we have the nfsv2 code then it
should do something better in this case :) As Jason says saturating
the value would be better than the current behaviour.

I'm happy enough to have a poke at it if no-one else is interested :)

David