Client support for 0-length virtual files

Client support for 0-length virtual files

[Atkinson, Sam]

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/tree/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?

Thanks very much,
Sam

Re: Client support for 0-length virtual files

[Trond Myklebust]

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@hammerspace.com