 |
 |
Hi Wei, storage-10-6 (like all of our dataservers) is using 4.10.0 as distributed by epel. Since this a migration from one data server to another the xrdadler32 is being executed from a dataserver and thus is also 4.10.0. I first noticed the problems under 4.9 and went to the latest version. Our OS is CentOS Linux release 7.6.1810 Now comes the oddity. I noticed that the problem was not being seen on one of our frontend machines and the main difference was it was using xrootd from the osg repos. I then ran some tests (from a compute node) on about 80K files that I have already migrated to storage-10-6. I ran three tests using xrootd-client installed from three different repos: osg (v4.10.0), epel (4.10.0), xrootd-stable(v4.10.1). For OSG there were no problems with getting checkums For Xrootd-Stable there were no problems. For the EPEL repo, there were problems with any path longer than 118 characters. Patrick On 9/30/19 8:48 AM, Yang, Wei wrote: > Hi Patrick, > > I initially thought this maybe a bug in xrdadler32 handling file name. It is not - I created a file in my storage and xrdadler32 can get its checksum: > root://atlrdr1//xrootd/atlas/atlasscratchdisk/rucio/user/bchargei/9c/d1/user.bchargei.data17_13TeV.physics_Main.DAOD_BPHY1.16_08_2019.v01.root.log.18890879.000052.log.tgz > > So what version of xrdadler32 are you using? What OS and xrootd server release are you running in storage-10-6? > > regards, > -- > Wei Yang | [log in to unmask] | 650-926-3338 (O) > > > On 9/29/19, 1:42 AM, "[log in to unmask] on behalf of Patrick McGuigan" <[log in to unmask] on behalf of [log in to unmask]> wrote: > > Hi, > > We are seeing an odd problem associated with performing checksums with xrdadler32. > > I am copying files from one data server to another using client commands. As part of the copy process I verify the adler32 checksum of the file on the destination server. This is what is having problems. > > The command that gets used works out to be: > > xrdadler32 root://storage-10-6//xrd/atlasscratchdisk/rucio/user/bchargei/9c/d1/user.bchargei.data17_13TeV.physics_Main.DAOD_BPHY1.16_08_2019.v01.root.log.18890879.000052.log.tgz > > and this fails with: > > Error_accessing: root://storage-10-6//xrd/atlasscratchdisk/rucio/user/bchargei/9c/d1/user.bchargei.data17_13TeV.physics_Main.DAOD_BPHY1.16_08_2019.v01.root.log.18890879.000052.log.tgz > > > However this command succeeds: > > xrdfs storage-10-6 query checksum /xrd/atlasscratchdisk/rucio/user/bchargei/9c/d1/user.bchargei.data17_13TeV.physics_Main.DAOD_BPHY1.16_08_2019.v01.root.log.18890879.000052.log.tgz > adler32 f4ac0c27 /xrd/atlasscratchdisk/rucio/... > > > I turned on XRD_LOGLEVEL=Dump and XRD_LOGFILE=xrootd-client-log > > and ran both commands above. The log is attached to message. > > > Of note in the dump of the failed command: > > The root URL is seemingly processed okay and the correct data server and path are identified > > The xrdadler32 command successfully logs into the remote server and performs an kXR_stat call > > The checksum is then seemingly retrieved via a kXR_query call. > > WHen this is done, the dump seems to indicate that the xrdadler32 command is then trying to contact a second URL which is a portion of the original path: > [2019-09-28 18:09:49.150535 -0500][Dump ][Utility ] URL: log.18890879.000052.log.tgz > > This of course fails, and the overall command seems to then fail. > > This is not happening for all the files, but it is happening randomly for some files with longer path names. > > > I was using version 4.9.1 and was seeing this and updated to version 4.10 which fixed one path, but I am still seeing the behavior with 4.10. > > > Any ideas what is going wrong here? > > Patrick > > > > > ######################################################################## > Use REPLY-ALL to reply to list > > To unsubscribe from the XROOTD-L list, click the following link: > https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1 > > ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-L list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1