Dear all,
I have a question, related to the CMS xrootd Federation that is
currently being established.
We currently have an storage element (dcache) with a normal
authenticated xrootd door (storage01), and files inside the CMS
namespace are named this way:
/pnfs/lcg.cscs.ch/cms/trivcat/this/is/my/file
And we have installed an xrootd redirector in another host (not inside
the dcache cluster) as specified here:
https://twiki.cern.ch/twiki/bin/view/Main/CmsXrootdArchitecture
And this redirector is called cmsvobox.
That host registers files into a xrootd manager, striping out the site
location from the filename, so files look like /this/is/my/file. And the
idea is that an external client can then connect to our redirector and
ask for:
cmsvobox:/this/is/my/file
And that should be redirected to our xrootd dcache door (storage01) to
the file:
storage01:/pnfs/lcg.cscs.ch/cms/trivcat/this/is/my/file
Redirect works, but we can't make it so that cmsvobox redirects *and
adds* the missing part of the filename.
cmsvobox xrootd relevant config looks like this:
all.manager xrootd.ba.infn.it:1213
oss.localroot /pnfs/lcg.cscs.ch/cms/trivcat
xrootd.redirect storage01.lcg.cscs.ch:1094 /
all.export / nostage readonly
oss.namelib /usr/lib64/libXrdCmsTfc.so
file:/etc/xrootd/storage.xml?protocol=direct
And the relevant part of storage.xml:
<lfn-to-pfn protocol="direct" destination-match=".*"
path-match="/+store/PhEDEx_LoadTest07/LoadTest07_[^/]+_CSCS/[^/]+/[^/]+/(.*)_.*_.*"
result="/pnfs/lcg.cscs.ch/cms/trivcat/store/phedex_monarctest/monarctest_CSCS-DISK1/$1"/>
<lfn-to-pfn protocol="direct" destination-match=".*"
path-match="/+(.*)" result="/pnfs/lcg.cscs.ch/cms/trivcat/$1"/>
<pfn-to-lfn protocol="direct" destination-match=".*"
path-match="/pnfs/lcg.cscs.ch/cms/trivcat/(.*)" result="/$1"/>
I have to admit I am not an xrootd expert, so any help would be really
appreciated!
Thanks,
BR/Pablo
PS: There may be an easy way out: creating a separate dcache xrootd
door, with a different port and a fake root
/pnfs/lcg.cscs.ch/cms/trivcat, and point the redirector to it... but it
seems to me much more dirty, compared with a generic xrootd (that could
equally serve ATLAS and CMS both) and a good name translation mechanism.
########################################################################
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
|