Print

Print


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