Following up on this, and as a test, I just successfully copied a test file (as the dteam VO) from our SE to a UI using xrdcp. There's no special VO configuration for dteam on our SE, so this demonstrates that VO specific configuration isn't needed for xrootd at a DPM site. (And it shouldn't be needed for dCache sites, either.)

Sam

On Thu, 30 Jul 2015 at 10:29 Sam Skipsey <[log in to unmask]> wrote:
hi Matt,

I'm not sure how other SE implementations set up xrootd access, but DPM sites should already support (all) VOs for xrootd access. (There's VO specific stuff for federation of sites, but that's really only a feature that ATLAS and CMS use).

Specifically, looking at the values that Dan mentions, on our xrootd config here, I see:

xrootd.export /

(we don't have an auth file for DPM sites, as authorisation is delegated to the DPM itself).

Can you tell us which SE endpoints you've tried using XrootD to access, so we can do some debugging?


Sam


On Thu, 30 Jul 2015 at 10:24 Matthew Mottram <[log in to unmask]> wrote:
Hi,

Is there any update following Dan’s comments on this?  Right now I’m unable to load any SNO+ files over XRootD.  I assume this is because access is not setup for the snoplus.snolab.ca VO.

This is an issue of increasing importance for us - right now we have no way to manage reprocessing of our raw datasets.

Cheers,
Matt

On 22 Jul 2015, at 09:45, Daniel Traynor <[log in to unmask]> wrote:

But are not the xrootd instances that have been set up by site atlas or cms only?i.e. in

/etc/xrootd/auth_file

I have only

u * /atlas rl

and in /etc/xrootd/xrootd-clustered.cfg

I have

all.export /atlas r/o

which I understand as only allowing access to atlas

how would you set up an xrootd server for another vo like snoplus?

dan

* Dr Daniel Traynor, Grid cluster system manager
* Tel +44(0)20 7882 6560, Particle Physics,QMUL

________________________________________
From: Testbed Support for GridPP member institutes <[log in to unmask]> on behalf of Brian Davies <[log in to unmask]>
Sent: 22 July 2015 09:14
To: [log in to unmask]
Subject: Re: Remote loading of Grid files for SNO+

Hi Matt,
The xrootd protocol should allow you to access nonROOT format files as well as ROOT format files and will allow you to stream the data from the storage system rather than copying the whole file to the local disk on the worker node.  ( Shaun DeWitt has some sample code for this if you are not already doing so.)
Brian

-----Original Message-----
From: Testbed Support for GridPP member institutes [mailto:[log in to unmask]] On Behalf Of Matthew Mottram
Sent: 20 July 2015 10:47
To: [log in to unmask]
Subject: Remote loading of Grid files for SNO+

Hi,

Gareth Smith suggested that someone on the TB support might be able to help on the issue of loading files remotely for SNO+.  Our processing jobs need to able to run over large datasets in single jobs (variable but potentially around 100 GB).  Until now we’ve just been splitting these jobs, with each sub-job downloading single files to local disk (via lcg-cp or gfal-copy) and then processing.  However, we’ve reached a point where we now know we need to process the entire dataset in a single job.  I know that we should instead load files over local network, but it’s not clear to me how to do this with e.g. XRootD.  Additionally, we may have some non-ROOT format files, in which case we would want in some way to map the LFN/SURL to a local path (while this is possible with lustre, I’m guessing it might not be possible with other storage systems).

I’ve compiled ROOT with XRootD, but as I understand it there are some extra configurations that we may need at each site in order to support our loading files from the SURL directly.  If anyone could advise me of the necessary steps (and whether these will also allow for loading of files from non-grid nodes as well - as some of our processing is better run on local batch systems) then I’d be very grateful.

The output datasets of the jobs will also be large.  We can have a script that runs in parallel with the jobs to push outputs to Grid storage as they are produced but if there’s a better (e.g. writing directly to Grid storage) then I’d be interested to hear of it.

Thanks,
Matt

-------------------------------------------------
Matthew Mottram
School of Physics and Astronomy
Queen Mary, University of London
-------------------------------------------------