NFS Server Scalability Improvement & Other NFS Enhancements For Linux 6.13

[jabl]

Yeah, in an enterprise environment you'll have (Free)IPA, AD, or something like that anyway, and once you have reached that point enabling Kerberos for NFS is just adding a mount option. Simple as pie.

[Kemosabe]

Oh right, the glorious NFS that is widely used and yet abysmally performing with no true alternative in sight that maybe would consider a modern approach from scratch. I hate NFS because at least the way it is always deployed it stands for issues.

[aviallon]

Just one look at NFS and you can see the problem. Authentication is based on IP address and the data is transferred over the network raw.

With NFSv4 there is a way to add encryption, but it's not native, it's ridiculously cumbersome to set up, and there is very little documentation on how to do it.

The way I do it is by tunneling my NFS over Wireguard.
Easy.

[JPFSanders]

Can you expand on this? I haven't heard about this before and I'm interested to know the reasoning behind it.

It is all based on issues that generally aren't a problem in the scenarios where NFS is useful, got to do with using IP addresses and non-encrypted data, something that in an enterprise/industrial is not an issue because storage generally sits alone in its own dedicated vlan behind a firewall.

[JPFSanders]

Oh right, the glorious NFS that is widely used and yet abysmally performing with no true alternative in sight that maybe would consider a modern approach from scratch. I hate NFS because at least the way it is always deployed it stands for issues.

Modern NFS has abysmal performance? Not in my experience.

[pong]

SSHFS is too slow for anything beyond trivial.

Don't get me wrong, it can be practical and I've used it in the past and was nice. But it is too slow and doesn't behave well when there are issues between client and server.

In my experience with lots-of-data-over-ssh transport (scp, rsync) and using "old" platforms (e.g. SOTA chips may be much better) the SSH options configured for host-to-host encryption and compression make a big (order of magnitude?) difference on achievable throughput doing streaming file copies from host to host.

I think the "default" mode probably has been to use some cipher that didn't (at least as of some years ago) have / use CPU instruction based acceleration so some faster crypto algorithm made a big difference in it not being CPU-bound for that purpose. Most desktop and IIRC mobile CPUs these data have AES support instructions so maybe achieving N-Gb/s or even N-GB/s rate "wire speed" crypto may be usually solved now?

As for compression, again, the difference between fast algorithms like say zstd and slower ones makes a big difference in data throughput even just considering stand alone compressor benchmarks (order of magnitude?) so configuring the right algorithm can help a lot.

Besides that then there's the FS level overhead which IDK how efficient that may be or not wrt. sshfs but I'd HOPE that it is usually (i.e. transferring lots of small files) efficient enough that it at least can pretty much match 'scp' throughput and easily enough saturate N-Gb/s wire speed rate for a typical home / small business host to server network.

So I am hypothesizing that a lot of the 'sshfs slow' problems might be user-tune-able as ssh level preferences host to host or as general defaults.

[s9209122222]

Just use SAMBA.