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
|