 |
 |
Most probably same issue as described in #1739 ... `xrdcopy` is able to recover / reopen connection (after quite long 120s timeout) while `gfal-copy` gets struck for fraction of transfers. This time DPM is not involved, but I'm just using CERN EOS with our XCache `xcache1.farm.particle.cz` (OSG package `xrootd-5.5.0-1.1.osg36.el7.x86_64` deployed by Slate), e.g. ```sh [lxplus.cern.ch]~% xrdcopy -f root://xcache1.farm.particle.cz//root://eosatlas.cern.ch//eos/atlas/atlasscratchdisk/SAM/1G file:///tmp/1G.xrdcopy [lxplus.cern.ch]~% gfal-copy --just-copy -f -t 60 root://xcache1.farm.particle.cz//root://eosatlas.cern.ch//eos/atlas/atlasscratchdisk/SAM/1G file:///tmp/1G.xrdcopy [lxplus.cern.ch]~% gfal-copy --version gfal2-util version 1.8.0 (gfal2 2.21.1) ... ``` Full log files from client [xrdcopy.log](http://vokac.web.cern.ch/vokac/tmp/xcache-20221026.xrdcopy.log) and [gfal-copy.log](http://vokac.web.cern.ch/vokac/tmp/xcache-20221026.gfal-copy.log). -- Reply to this email directly or view it on GitHub: https://github.com/xrootd/xrootd/issues/1808 You are receiving this because you are subscribed to this thread. Message ID: <[log in to unmask]> ######################################################################## 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