Hi Nikolai,

I don't think the fd growth and file contents errors are related.

About the file errors, people doing ATLAS tests in the US saw exactly the same symptom in about the same time-frame - certain blocks of a file being "all zeros". It was traced down to some network/storage/proxy SNAFU at ATLAS SW T2. Is it possible you pulled the files from that site, too? Nevertheless, we are working on providing a way to detect such errors in the caching proxy. Mind you, you would see the same problem were you to transfer the file using xrdcp ... so we really need either a protocol level checks or a way for caching proxy to retrieve checksums from some service providing them.

About the rising number of fds, this will only happen when caching proxy is seriously overloaded, i.e., it is not able to write data to disk and those writes are also competing with reads for data that is already on the disk. Can you please describe your setup (xrootd config, disk configuration being used) and expected number of jobs and their read rates? Also, can you please show machine load and network in/out plots for the same time interval, say, 17.5. to 19.5. [ Of course, there is also a possibility that something else is going wrong, that's why Andy was asking about details of what kind of fds are leaked ... however, the ratio of files to sockets of 2 : 1 is indicative of the fd leak related to ciosync (2 files (data + cinfo) and 1 socket to the remote). ]

The bytes_missed simply means that XCache has its write queue full and so served that many bytes to local clients by directly forwarding the request to the remote, without trying to write it to disk.

Cheers,
Matevz

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

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