 |
 |
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