On Wed, 10 Dec 2025 06:11:02 -0000 (UTC) [email protected] (Michael van Elst) wrote:
> Saying that, NFS is not ideal for building, there is lots of latency > added to even traversing file paths, and with many files (like in > a pbulk scenario), the filesystem caches won't be effective. I have two Raspberry Pi 4 SOCs and each has Samsung T7 SSD attached to USB3 port. For sequential writes using 64 KiB block size I get these metrics: NetBSD-10 local UFS file system: 5717.50 msec, 179.10 MiB/sec, 2865.59 Blocks/sec, 348.97 usec/Block NetBSD-10 NFSv3 network share: 10923.26 msec, 93.74 MiB/sec, 1499.92 Blocks/sec, 666.70 usec/Block ---------------------------------------- Debian-12 local XFS file system: 9138.81 msec, 112.05 MiB/sec, 1792.79 Blocks/sec, 557.79 usec/Block Debian-12 NFSv3 network share: 16048.65 msec, 63.81 MiB/sec, 1020.90 Blocks/sec, 979.53 usec/Block I did not expect NetBSD NFSv3 server to outperform Linux NFSv3 server. The only tuning I did was to specify 16 NFS server threads on both machines. I did have some issues with NFS file locking when running NetBSD build.sh from a 16-core Linux client, but I worked around those by mounting NFS shares with nolock,local_lock=all options. After that building on NFS shares (both source and object files kept there) works pretty well.
