Print

Print


Hi Patrick,

what version of xrootd client (and server) are you using?

regards,
--
Wei Yang  |  [log in to unmask]  |  650-926-3338 (O)
 

´╗┐On 2/19/20, 5:49 AM, "[log in to unmask] on behalf of Patrick McGuigan" <[log in to unmask] on behalf of [log in to unmask]> wrote:

    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