Hi,
I ran into an issue with xrdadler32 that may or may not be a bug.
My dataservers and redirector are running version xrootd 3.3.6
The dataservers are configured with the line:
xrootd.chksum max 4 adler32 /usr/bin/xrdadler32
so that checksums are stored in the extended attributes of the native XFS file
system. This works fine.
Originally the redirector did not have a similar line but during debugging I added:
xrootd.chksum adler32 /usr/bin/xrdadler32
I had to reinstall a client machine (an SRM host) based on the OSG software
stack. The installation brought in version 4.6.1 for xrootd-client,
xrootd-fuse, xrootd-libs, xrootd-client-libs. Specifically the packages are:
<package>-4.6.1-1.osg33.el6.x86_64
After installation I ran into problems with code that uses xrdadler32 to
retrieve checksums from files that are normally mounted via xrootdfs. The code
that uses xrdadler32 exports an XROOTD_VMP so that calls are translated to
native xroot URL's. The problem was that the code was not retrieving the
checksum, but instead, calculating the checksum on the SRM host which required
the SRM host to read the entire file locally.
I tracked this back a little bit and discovered that if I used
/usr/bin/xrdadler32 with an xroot URL (with the redirector as host), then the
checksum would be performed without a checksum being stored on the dataservers
native file system using extended attributes. If the xroot URL used the correct
dataserver as the host, then the checksum was stored.
I downgraded the xrootd installation on the SRM host to version
xrootd-client-4.5.0-2.osg33.el6.x86_64 and everything seems to be working properly.
I am not sure if this is a bug, given the age of the dataserver installation,
but I was encouraged to report it.
Regards,
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
|