 |
 |
Hi Andy, My version 3.3.6 redirector now uses: xrootd.chksum adler32 /usr/bin/xrdadler32 but the version 4.6.1 xrdadler32 still has the problem. Should I remove the callout to /usr/bin/xrdadler32? Version 4.5.0 seems to be okay. I am happy with my solution since the SRM's days are limited and we will be doing a software update on the dataservers/redirector in the near future. Regards, Patrick On 08/16/2017 11:45 AM, Andrew Hanushevsky wrote: > Yes, the issue we fixed (that people were complaining about) that issuing a > checksum request to the redirector didn't redirect. So, we fixed that but that > also meant the redirector needed to be told about checksums (I believe we did > that for backward compatabilty). Clearly, we didn't succeede relative to your > particular setup. So, while I don't (yet) understand why this behaviour occurs, > I do thnk that adding that line will correct the issue. > > Andy > > On Wed, 16 Aug 2017, Yang, Wei wrote: > >> So Patrick, the problem you reported is that in 4.6.1 xrdadler32 doesn˙˙t >> trigger a server side checksum calculation when xrdadler32 reached to the >> redirector, and only trigger server side calculation when going directly to >> the data server? >> >> I am running 4.4.0 for production and I don˙˙t see this issue. I recently run >> into a similar issue on a test cluster with 4.6.1 and Andy told me that adding >> ˙˙xrootd.chksum xrdadler32˙˙ to the redirector should address this issue. That >> seems to work but I will try it again. >> >> regards, >> -- >> Wei Yang | [log in to unmask] | 650-926-3338(O) >> >> >> >> >> >> >> >> >> On 8/16/17, 2:24 AM, "[log in to unmask] on behalf of Patrick >> McGuigan" <[log in to unmask] on behalf of [log in to unmask]> wrote: >> >>> 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 >> >> ######################################################################## >> 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 ######################################################################## 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