Re: Subtle NFS incompatibility with SunOS 4.1.1 on 68K

[Chris Hanson <cmhanson%eschatologist.net@localhost>]

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?

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?)

> 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.

  -- Chris