 |
 |
Hi Patrick, Could run xrdfs query checksum for both xrootd.chksum adler32 /usr/bin/xrdadler32 and xrootd.chksum max 4 adler32 xrdfs just echos the response it got from the server, xrdcp is more picky and expects that the buffer will contain both checksum name and value. Cheers, Michal ________________________________________ From: [log in to unmask] [[log in to unmask]] on behalf of Patrick McGuigan [[log in to unmask]] Sent: 19 February 2020 14:16 To: [log in to unmask] Cc: [log in to unmask]; xrootd-l Subject: Re: Yet another checksum question Hi Andy, From the host storing the file: [root@storage-5-18 ~]# xrdadler32 root://localhost//xrd/srm-test/mover-test.1 063301c4 /xrd/srm-test/mover-test.1 root://localhost//xrd/srm-test/mover-test.1 Patrick On 2/19/20 7:12 AM, Andrew Hanushevsky wrote: > Hi Patrick, > > Uhmmm, how about the output of the xrdadler command run on the server against > the same file the query checksum is beig targeted? > > Andy > > On Wed, 19 Feb 2020, Patrick McGuigan wrote: > >> Hi Andy, >> >> [root@admin ~]# xrdcp -np -f --cksum adler32:print test-transfer >> root://storage-5-18:1094//xrd/srm-test/mover-test.1 >> Run: [ERROR] Invalid response >> [root@admin ~]# echo $? >> 53 >> >> Attached is the output of the same command with the -d3 switch (the >> transferred file is 4 bytes). >> >> Patrick >> >> >> On 2/19/20 5:58 AM, Andrew Hanushevsky wrote: >>> Hi Patrick, >>> >>> Coud run that command by hand on a failing file and post the output as well >>> as what the return code was. >>> >>> Andy >>> >>> >>> On Wed, 19 Feb 2020, Patrick McGuigan wrote: >>> >>>> Hi Andy, >>>> >>>> It is the command from the xrootd-client rpm. >>>> >>>> Patrick >>>> >>>> On 2/19/20 5:45 AM, Andrew Hanushevsky wrote: >>>>> Goo question Rob. We provide the xrdadler command but not a script. So,t he >>>>> first question should have been is this a script or the actual command. >>>>> >>>>> Andy >>>>> On Wed, 19 Feb 2020, Robert Gardner wrote: >>>>> >>>>>> Who provides said external script? >>>>>> >>>>>> >>>>>>> On Feb 19, 2020, at 5:34 AM, Andrew Hanushevsky >>>>>>> <[log in to unmask]> wrote: >>>>>>> >>>>>>> Hi Patrick, >>>>>>> >>>>>>> In the first case, the config says hat an external script is supposed to >>>>>>> computed the checksum. If the external script produces an incorrect >>>>>>> response, the client will get it and complain. The second case says that >>>>>>> the checksum is to be computed using the internal native mechanism. In >>>>>>> this case, a corect response will always be sent. Hence, it will work. We >>>>>>> reccomend that the internal mechanism be used when it is possible to do >>>>>>> so. That said, ot would be interestin to know what the hiccup is in the >>>>>>> external script. >>>>>>> >>>>>>> Andy >>>>>>> >>>>>>> On Wed, 19 Feb 2020, Patrick McGuigan wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I noticed something odd recently and I am curios if the issue is a known >>>>>>>> feature, or something that needs to be worked on? >>>>>>>> >>>>>>>> A client process was moving files with xrdcp using: >>>>>>>> >>>>>>>> xrdcp -f -np --cksum adler32:print test-transfer >>>>>>>> root://some-server//some-path >>>>>>>> >>>>>>>> and the command fails with: >>>>>>>> >>>>>>>> Run: [ERROR] Invalid response >>>>>>>> >>>>>>>> Tracking this down leads me to the problem in the data server's >>>>>>>> configuration: >>>>>>>> >>>>>>>> xrootd.chksum adler32 /usr/bin/xrdadler32 >>>>>>>> >>>>>>>> >>>>>>>> However, if the checksum is configured as: >>>>>>>> >>>>>>>> xrootd.chksum max 4 adler32 >>>>>>>> >>>>>>>> The xrdcp will work correctly. >>>>>>>> >>>>>>>> >>>>>>>> Before anyone asks, yes, checksums work correctly outside of xrdcp: >>>>>>>> >>>>>>>> xrdadler32 root://some-server//some-path >>>>>>>> >>>>>>>> as well as: >>>>>>>> >>>>>>>> xrdfs some-server query checksum /some-path >>>>>>>> >>>>>>>> >>>>>>>> I have seen this occur with versions 4.9.1 and 4.10.0. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 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 >> ######################################################################## 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