I seem to have problems with nfs shared files after the latest nfsv4.1 integration.

Sometimes reading files via nfs fails with errors. I haven't found a way to trigger them reliably but they happen often when I try to unpack source files on remote hosts.

I have a share folder userland-sources where all downloaded source archives are kept.

When runnung a BE of before April 16th everything works reliably. Newer BE's have this problems sooner or later.

I have the impression that I can "fix" the problem when I unpack the file once on the nfs server when this happens.

wacki: is the newer BE on the client or the server? what exact errors do you get when you get read errors? are you unpacking remote files to a local filesystem or an nfs mounted filesystem?

if you can get a packet capture, that'd be helpful as well..

Server and clients were all latest. The clients are my build machines and update after every jenkins job has been finished. Booting an old BE on the file server machine fixed the problem.

What I got in an error situation was corrupt archive (eg. zip archive) or "this is not an archive" (tar).

At the moment my main client is busy building nodejs. If that is finished I can activate the latest BE on the server and try to reproduce the problem.

It's not happening every time I unpack something but when it happens I can typically reproduce the same error a couple of times until it succeeds in the end.

so corrupted data on reads. ick!

were the archives recently modified/newly stored? were they written over NFS or written locally on the server?

and were they written from the same client or from a different client?

(if written over NFS)

Typically they are new and written by the clients. The files are definitely correct because I can unpack them on the server when the problem occurs.

After unpacking the archive on the server it can also successfully be unpacked on the client (at least I have this impression; too few data points to be sure).

same client or different client?

I only have tried on the same client.

have you modified the server_vers{min,max} options (see nfs(5)) ? from looking at the testing notes for the NFS change I see a lot of testing against other people's NFS clients but not so much against our client.

Yes, it was 4.1 but is now 4 and this didn't change anything.

I have booted the latest BE now. I have succerssfully unpacked an old nodejs-22 package but nodejs-20 failed:

╰─➤ gmake unpack

/export/home/andreas/oi-userland/tools/userland-fetch --file /Daten/ungesichert/OpenIndiana/userland-sources/node-v20.20.0.tar.xz --url nodejs.org/dist/v20.20.0/node-v20.20.0.tar.xz --hash sha256:5294d9d2915620e819e6892fd7e545b98d650bad36dae54e6527eaac482add98

INFO: not using any hashes in /net/master/Daten/ungesichert/OpenIndiana/userland-sources/hashes for node-v20.20.0.tar.xz (overridden with --hash)

Source /net/master/Daten/ungesichert/OpenIndiana/userland-sources/node-v20.20.0.tar.xz... cached

validating signature... checking local signature... not found

signature validation failed

validating hash... ok

/usr/bin/touch /Daten/ungesichert/OpenIndiana/userland-sources/node-v20.20.0.tar.xz

/bin/rm -f -r /export/home/andreas/oi-userland/components/runtime/node20/node-v20.20.0

/usr/bin/env -i RUBY_VERSION=3.2 /export/home/andreas/oi-userland/tools/userland-unpack /Daten/ungesichert/OpenIndiana/userland-sources/node-v20.20.0.tar.xz

/usr/bin/xz: /Daten/ungesichert/OpenIndiana/userland-sources/node-v20.20.0.tar.xz: Read error: Unknown error

gtar: This does not look like a tar archive

gtar: Exiting with failure status due to previous errors

/usr/bin/touch /export/home/andreas/oi-userland/components/runtime/node20/node-v20.20.0/.unpacked

touch: cannot create /export/home/andreas/oi-userland/components/runtime/node20/node-v20.20.0/.unpacked: No such file or directory

gmake: *** [/export/home/andreas/oi-userland/make-rules/prep-unpack.mk:78: /export/home/andreas/oi-userland/components/runtime/node20/node-v20.20.0/.unpacked] Error 1

the client is OI, I take it?

Yes

I run OI on the server and 4 clients.

I try to keep them all up-to-date.

in that case the server version does not matter, our client is 4.0

The clients are being used as desktop systems and devleopment machines for OI.

I can run a test from a FreeBSD (GhostBSD) client and see whether that can successfully unpack nfs mounted files from the server.

gunzip was ok (I tested with boot_archive)

but you have xz

unzip has the same problem.

And the problem doesn't always occur. Sometimes unpacking works the first time, sometimes later. If I repeat often enough I can unpack all packages.

ok. need to walk the dog, then can continue testing...

This happened on April 16th the first time but I wasn't suspecting the nfs server first.

The GhostBSD client doesn't seem to have problems. I have successfully checked dozens of files.

btw src.illumos.org/source does respond with 502 Bad Gateway