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