Replies: 1 comment 7 replies
-
|
This is of course not a nice solution for NFS clients, as then try to optimize IO requests based on the file size.... You can always return Long.MAX_VALUE ans the file size, and return less bytes and set EOF flag on read: bool eof = false;
final READ4res res = result.opread;
int n;
try {
n = vfs.read(...);
res
} catch (EOFException e) {
res.resok4.eof = true;
} You will need to implement a custom READ operation to use it: class CustomNFSv4OperationFactory extends MDSOperationExecutor {
@Override
protected AbstractNFSv4Operation getOperation(nfs_argop4 op) {
switch (op.argop) {
case nfs_opnum4.OP_READ:
return new CustomOperationREAD(op);
default:
return super.getOperation(op); |
Beta Was this translation helpful? Give feedback.
-
|
Once the file is opened, I'm not seeing any further GETATTR calls for the file. During OPEN, we pass Long.MAX_VALUE as the file size (as was suggested in the earlier post), then we don't see another GETATTR until the file is closed. We have a test that runs a database query that returns 4118 bytes. It's triggered by the client mounting our filesystem, then doing something like "cat test". The flow we see on the server looks like this: Once the file is opened, we see the data being read: We're given a large (512K) buffer, so the entire output fits in this first buffer. We return the full 4118 bytes, we set res.resok4.eof = true and res.status = nfsstat.NFS_OK. On the client, this data is received properly. But instead of detecting the EOF, the client comes back to us with another read: We detect that this is a read after EOF, so this one returns an empty buffer, with res.resok4.eof = true and res.status = nfsstat.NFS_OK. The pattern of SEQUENCE/PUTFH/READ just loops indefinitely at this point. There are no other operations - no GETATTR, etc - until we break out of the client program and then we see the file being closed. It's as though the client ignores the EOF marker we send and it's just looping until it gets Long.MAX_VALUE bytes returned. We're thinking to run a network trace on the client to verify that the EOF flag is being set properly, but otherwise, we're at a loss. Any ideas you have are definitely appreciated! |
Beta Was this translation helpful? Give feedback.
-
|
Hm.. Can you provide packet capture (tcpdum -i /tmp/nfs.pca port 2049)? |
Beta Was this translation helpful? Give feedback.
-
|
Sure - here you go...it's the same scenario as above, but this time the data we're sending is 4518 bytes. I see this in Wireshark - note the eof = 1 flag: After this, we see the same sequence of OP_READ requests as I described earlier - EOF is still set, but there's no data length or buffer being returned: If it's important, this is Ubuntu 22.04, but I believe we had the same issue under 18.04 and 20.04 as well. Thanks for your help! |
Beta Was this translation helpful? Give feedback.
-
|
Ok, so here is what is happening. As your file is quite big (according to the size), the nfs client issues multiple READ requests in parallel. Some of them (one) get the data, and the others get zero bytes + EOF. As expected (see above) the client gets confused, and issues GETATTR (frames 144-154): As the file use is still reported as MAX_VALUE |
Beta Was this translation helpful? Give feedback.
-
|
Thank you very much for this...I'm no slouch, but it would have taken me a long time to figure out that the NFS client was sending parallel requests for the same file, but that does make sense. I tried a quick test to verify this is indeed what's happening. Since I know my test data is 4-5K, instead of returning Long.MAX_VALUE for the file size, I just returned something bigger than my data can be. When I returned 32K as the length, the client seems to be behaving properly now. I'll enhance my code to track of the actual size of the dynamic output we're generating and then return this value on GETATTR once the dynamic output is finalized. From what I'm seeing, that should work fine. Thanks again for your help! |
Beta Was this translation helpful? Give feedback.
-
Apologies if this is a newbie question - still figuring out the nitty-gritty details of NFS as well as the nfs4j implementation.
It seems nfs4j normally requires the server to know the size of files being accessed before the file data is fetched...when a client reads a file, the server seems to get the size, then calls the VFS layer to fetch precisely this much data.
Is there an alternative where the server can just read until it gets EOF from the VFS implementation? This is very handy when the underlying object isn't a filesystem object, but rather a pipe, a database query or some other "blob" where it's difficult or time-consuming to know the precise size involved ahead of time. What we're looking for (perhaps) is a way to set the size attribute to something like -1 (or not return it at all), then throw some sort of EOF exception to tell the system that a particular filehandle reached the end of its data.
Beta Was this translation helpful? Give feedback.
All reactions