Hi Andrew,
that's a pity, but thank you for your confirmation on this.
Ciao,
Xavier.
> -----Original Message-----
> From: Andrew Hanushevsky [mailto:[log in to unmask]]
> Sent: Saturday, August 30, 2014 3:12 AM
> To: Mol, Xavier (SCC)
> Cc: [log in to unmask]; Petzold, Andreas (SCC)
> Subject: RE: Redirect rules based on translated paths
>
> Hi Xavier,
>
> Ah, now I understand. The match occurs *before* any name to name
> translation. I suppose this is implicit as this applies to xrootd which
> "namelib" applies to the oss (storage system) which id merely used by
> xrootd via the ofs layer (file system). So, the answer is no, it can't be
> done using the current mechanism. So, the only other way to do this is =to
> come up with a custom ofs plug-in. Typically, this would be a simple
> wrapper plug-in to the existing one. The CMS throttle plugin works in this
> fashion and it's pretty easy to do.
>
> Andy
>
> On Fri, 29 Aug 2014, Mol, Xavier (SCC) wrote:
>
> > Hi Andrew,
> >
> > we already read the documentation about redirect and that is the reason why we thought our setup might work in the first place.
> However, key information is missing in the documentation, that the paths supplied to xrootd.redirect are matched against the original
> path the client delivered and not after it has been extended/changed by e.g. localroot or oss.namelib. That is the reason why the simple
> idea doesn't work out as intended for us. We want to redirect the client to the right place after path modification was performed by the
> CMS trivial file catalogue, applied through oss.namelib.
> >
> > Please tell us, if we misunderstood the documentation or point out our error in the xrootd-clustered.cfg file.
> >
> > Thank you for your attention.
> >
> > Ciao,
> > Xavier.
> >
> >> -----Original Message-----
> >> From: Andrew Hanushevsky [mailto:[log in to unmask]]
> >> Sent: Friday, August 29, 2014 4:59 AM
> >> To: Mol, Xavier (SCC)
> >> Cc: [log in to unmask]; Petzold, Andreas (SCC)
> >> Subject: Re: Redirect rules based on translated paths
> >>
> >> Hi Xavier,
> >>
> >> Indeed, you can. However, you will need to setup a simple XRootD server
> >> and tell it how you want to fan-out the redirections. That will become the
> >> primary point of contact and clients will be redirected as configured. You
> >> use the xrootd.redirect directive to do this. The link totyhe explanation
> >> is below.
> >>
> >> http://xrootd.org/doc/dev4/xrd_config.htm#_Toc383723530
> >>
> >> Andy
> >>
> >> On Thu, 28 Aug 2014, Mol, Xavier (SCC) wrote:
> >>
> >>> Hello xrootd community,
> >>>
> >>> I have a question regarding the xrootd.redirect feature, similar to what was asked before in a mail from Pablo Fernandez
> >> ("xrootd.redirect changing the namespace", https://listserv.slac.stanford.edu/cgi-bin/wa?A2=XROOTD-L;87c83b90.1302): Can we make
> >> xrootd apply the redirect rule to a path _after_ name conversion was done?
> >>>
> >>> Like Pablo, we also have a dCache storage element with a xrootd data server in front of it, that will always redirect to a dCache
> xrootd
> >> door. This time however, we want to have the xrootd redirector choose between two different dCache instances based on the path the
> >> client requests. The xrootd.redirect setting seems ideal for this, but there is one problem: When using a path with the redirect
> statement,
> >> this path is matched against the file name the client provided to xrootd. But we would like xrootd to match it against the PFN, that will
> >> result out of the name mangling done by the CMS trivial file catalogue (TFC) (see oss.namelib in the attached cfg). It is fine that the
> client
> >> keeps its original file name, the very same name conversion will be done by the dCache xrootd door again.
> >>>
> >>> To explain our situation in more details, in case you are wondering what we tried so far...
> >>> On the xrootd data server, we have mounted the dCache namespace on /pnfs/gridka.de/cms. The client usually comes with file
> names
> >> beginning with '/store', which the CMS TFC will change into '/pnfs/gridka.de/cms/disk-only/store' (always prepending
> >> '/pnfs/gridka.de/cms/disk-only'), the PFN xrootd will perform the lookup task with. Upon successful lookup, the client will always get
> >> redirected to cmsxrootd-kit.gridka.de:1094, thanks to the current active redirection rule (based on the path '/'). What we tried to do
> now
> >> is mounting the name space of a second dCache instance on /pnfs/gridka.de/dcms, right next to the previous one, and introduce two
> >> redirection rules like this:
> >>>
> >>> # xrootd.redirect cmsxrootd-kit.gridka.de:1094 /
> >>> xrootd.redirect cmsxrootd-kit.gridka.de:1094 /pnfs/gridka.de/cms
> >>> xrootd.redirect f01-031-117-e.gridka.de:1094 /pnfs/gridka.de/dcms
> >>>
> >>> After restart of xrootd+cmsd, whenever we tried to read a file, the client failed in a weird way. The file lookup still was successful
> (since
> >> we changed nothing about that), but then an input/output error occurred for xrootd, like this one:
> >>>
> >>> 140827 16:57:15 807 XrootdXeq: mol.11144:[log in to unmask] login
> >>> 140827 16:57:15 807 mol.11144:[log in to unmask] XrootdProtocol: endsess 409:23.6
> >>> 140827 16:57:15 807 mol.11144:[log in to unmask] ofs_open: 0-600 fn=/store/mc/Summer12/(...)
> >>> Resulting PFN: /pnfs/gridka.de/cms/disk-only/store/mc/Summer12/(...
> >>> 140827 16:57:15 807 mol.11144:[log in to unmask] ofs_fstat: fn=/store/mc/Summer12/(...)
> >>> 140827 16:57:15 807 XrdLink: Unable to send file to mol.11144:[log in to unmask]; input/output error
> >>> 140827 16:57:15 807 XrootdXeq: mol.11144:[log in to unmask] disc 0:00:00 (sendfile failure)
> >>> 140827 16:57:15 807 mol.11144:[log in to unmask] ofs_close: use=1 fn=/store/mc/Summer12/(...)
> >>>
> >>> Yes, we made sure that the file does actually exist, before we tried to read it. Only after we reverted the redirect path back to '/' or
> >> '/store', we were able to read the file again successfully.
> >>>
> >>> So stating the question again, can we make xrootd respect the PFN for redirect decision making? Since the PFN doesn't leave xrootd
> >> anymore, that might somehow be done using a trigger we failed to find so far?
> >>>
> >>> Of course, if you have ideas of how we can solve the problem in a different way, please tell us. If at all possible, we would like to keep
> >> this one xrootd data server and not set up a second, independent one, or introduce a xrootd manager in front of the data server. E.g. if
> we
> >> could somehow make xrootd perform two file lookups, then we could first try with '/pnfs/gridka.de/cms' as prefix and only if that fails,
> try
> >> again using '/pnfs/gridka.de/dcms' and redirect based on the results. Our expertise unfortunately is not sufficient to find a way to
> achieve
> >> either of the solutions.
> >>>
> >>> Thank you very much for your attention.
> >>>
> >>> Ciao,
> >>> Xavier.
> >>>
> >>> ****
> >>> Karlsruher Institute of Technology (KIT)
> >>> Steinbuch Centre for Computing (SCC)
> >>>
> >>> B. Sc. Xavier Mol
> >>> GridKa Storage Administrator and Support Manager
> >>>
> >>> Hermann-von-Helmholtz-Platz 1
> >>> Geb. 449
> >>> 76344 Eggenstein-Leopoldshafen
> >>> Phone: +49 721 608 23041
> >>> Email: [log in to unmask]
> >>> www.kit.edu
> >>> KIT - University of the State of Baden-Württemberg and National Large-scale Research Center of the Helmholtz Association
> >>> ****
> >>>
> >>>
> >>> ########################################################################
> >>> 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
