On Wed, Mar 23, 2022 at 11:26:11AM +0100, Bernd Schubert wrote: > Add in network file systems. Demonstrating that this is useful > locally and with micro benchmarks - yeah, helps a bit to make it > locally faster. But the real case is when thousands of clients are > handled by a few network servers. Even reducing wire latency for a > single client would make a difference here. > > There is a bit of chicken-egg problem - it is a bit of work to add > to file systems like NFS (or others that are not the kernel), but > the work won't be made there before there is no syscall for it. To > demonstrate it on NFS one also needs a an official protocol change > first. I wouldn't assume that. NFSv4 already supports compound rpc operations, so you can do OPEN+READ+CLOSE in a single round trip. The client's never done that, but there are pynfs tests that can testify to the fact that our server supports it. It's not something anyone's used much outside of artificial tests, so there may well turn out be issues, but the protocol's definitely sufficient to prototype this at least. I'm not volunteering, but it doesn't seem too difficult in theory if someone's interested. --b. > And then applications also need to support that new syscall > first. > I had a hard time explaining weather physicist back in 2009 that it > is not a good idea to have millions of 512B files on Lustre. With > recent AI workload this gets even worse. > > This is the same issue in fact with the fuse patches we are creating > (https://lwn.net/Articles/888877/). Miklos asked for benchmark > numbers - we can only demonstrate slight effects locally, but out > goal is in fact to reduce network latencies and server load. > > - Bernd
