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
