On Tue, 2024-02-27 at 13:04 +0000, Atkinson, Sam wrote: > Hello, I am looking for thoughts/guidance on exposing 0-byte virtual > files (implemented with seq_file) over NFS. > > I have had success exposing these 0-byte files with nfsd and reading > the files from a client with third-party userspace clients > (https://github.com/CharmingYang0/NfsClient specifically), but I am > hitting a roadblock with the Linux NFS client. When the file size is > 0, the client seems to give up and return from the syscall before > making a read request to the server, even when an application > explicitly issues a syscall with a non-zero length > (https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tre > e/fs/nfs/read.c?h=v5.10.210#n125). > > As far as I can see, there is nothing in the NFS spec indicating that > clients should behave in this way. But I realize that making any > change in this behavior could introduce additional round-trips > whenever the client thinks the file length is shorter than the > server. Could anyone share context or thoughts on why this is the > behavior in the Linux NFS client and/or thoughts on paths forward? > Would folks here entertain a patch proposal which removes said > behavior, maybe configurable with a client-side module param or > control file? > If you can make it work with O_DIRECT, then have at it. However I'm not prepared to accept any hacks to the standard cached filesystem APIs to try to tunnel through uncacheable I/O from pseudofiles that are acting like pipes or sockets. The expectation for most NFS clients is that they should be able to cache attributes as well as data, since otherwise they can cache neither one. Userspace clients that don't offer caching are, of course, quite free to act differently. O_DIRECT can do the same, with certain limitations. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
