 |
 |
Hi @simonmichal ,
To be a bit more specific, we have the suspicion that the RAL server (under some currently unclear conditions) will respond to the final read request with an kXR_oksofar status. It then delivers an additional response. This causes the dCache embedded client to accept data that is too long; however, because xrdcp truncates the file to the expected size, the correct file size is delivered the to local filesystem.
Using your example but targeting a 9MB file and with the server replying with 2MB chunks. The client requests 4MB at offset 0. The server delivers 4MB of data but split into two chunks, each 2MB in size. The first has the status kXR_oksofar while the second is kXR_ok.
The second read request (at offset 4MB) shows the same behaviour: two responses, each 2MB in size with kXR_oksofar and kXR_ok respectively.
The third read request (at offset 8MB) is for 4MB. The server replies with the remaining 1MB (as expected) but with the status kXR_oksofar, indicating that further data will be deliverd. It then replies with an additional response which is 2MB with the status kXR_ok.
In total, the server tried to deliver 11MB of data, despite the file being 9MB in size.
I believe that, when xrdcp sees this behaviour from the server, it will write a file of the expected file size. It will also not issue a warning to the user that the server tried to deliver too much data.
I think it is fine for xrdcp to truncate the file; however, I also think that xrdcp should emit a warning if the server includes the kXR_oksofar status when sending what should be the final response and/or otherwise tries to deliver too much data.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1