Hi Gregory,
On Thu, Mar 24, 2005 at 05:22:15PM +0100, Gregory Schott wrote:
> I am trying to export 3 different disks. I am using xrootd version
> 20050110-1339. I tried:
>
> xrootd.export /export/babar13/kanga/EventStore/store
> xrootd.export /export/babar14/kanga/EventStore/store
> xrootd.export /export/babar15/kanga/EventStore/store
Note that this allows clients to access things externally as:
root://host:port///export/babar13/kanga/EventStore/store/blaXXX
root://host:port///export/babar14/kanga/EventStore/store/blaYYY
root://host:port///export/babar15/kanga/EventStore/store/blaZZZ
etc.
so it really isn't what you want. (You basically are letting some of the
details of the filesystems be visible externally.)
> oss.localroot /export/babar13/kanga/EventStore/
> oss.localroot /export/babar14/kanga/EventStore/
> oss.localroot /export/babar15/kanga/EventStore/
> xrootd.export /prod
> xrootd.export /store
>
> but neither worked (in the second case it works for babar15 only). Could
> you send me an example of your working setup?
Using the "oss.localroot" directive is the right thing, since that allows
you hide the details of the local filesystem, so that clients can access
things as:
root://host:port//store/blaXXX
root://host:port//store/blaYYY
root://host:port//store/blaZZZ
etc.
The problem you have here is that each xrootd wants to see a _single_
filesystem (with root=localroot) to export. By putting in three "localroot"
directives, I assume that only the last one is kept as valid.
We just went through some of these things today at CNAF WRT gpfs (I
recognize this is what you are using here). The solutions are:
a) use the cache filesystem to tie the three gpfs filesystems together
into one "namespace" to export (This is what is done at SLAC and most
of the other sites that have more than one filesystem/server.) See:
http://xrootd.slac.stanford.edu/doc/mps_config/mps_config.htm
(I _really_ need to provide a simple example of this.)
b) Run one xrootd per gpfs filesystem (since they are o(8TB) each, this
probably isn't a disaster.
The fundamental issue here is that gpfs is trying to do one of the things
that xrootd is trying to do, namely load balancing across the fileservers.
They aren't incompatible, but the part that gpfs doesn't do (allow the
separate filesystems to be treated as a single logical file space) has to be
dealt with some way. The choices are really (a) or (b) above. (Or _really_
ugly solutions, like the current one being used by some of LHC experiments
where the location of the file on a particular filesystem is being managed
by an external catalog....)
Does that help?
Pete
> On Sun, 27 Feb 2005, Andrew Hanushevsky wrote:
>
> > Hi Matt,
> >
> > Stephen is right. THe performance will not be very good. While you have
> > eased the load on nfs in terms of number of clients the overall speed will
> > be limited to below nfs speeds. In general, nfs is a very poor performer.
> >
> > Andy
> >
> > On Sun, 27 Feb 2005, Stephen J. Gowdy wrote:
> >
> >> Hi Matt,
> >> BTW, do you really want to serve an NFS disk via xrootd? I'm not
> >> sure what the benefits would be, perhaps teher server would cache the file
> >> to make it a little better than normal NFS if a lot of people open the
> >> same file...
> >>
> >> regards,
> >>
> >> Stephen.
> >>
> >> On Sun, 27 Feb 2005, Langston, Matthew David wrote:
> >>
> >>> We would like to export multiple directories from our xrootd server. The version of xrootd we are running currently only supports exporting one directory. This is our current xrootd.cf file:
> >>>
> >>> glast@glast01 $ cat xrootd.cf
> >>> xrootd.fslib libXrdOfs.so
> >>> oss.readonly
> >>> xrootd.export /nfs/farm/g/glast/
> >>>
> >>> We would like to do something like this:
> >>>
> >>> glast@glast01 $ cat xrootd.cf
> >>> xrootd.fslib libXrdOfs.so
> >>> oss.readonly
> >>> xrootd.export /nfs/farm/g/glast/dir1
> >>> xrootd.export /nfs/farm/g/glast/dir2
> >>>
> >>> However, it appears that xrootd only takes the last "xrootd.export" stanza. Is there a way to get multiple exports (maybe in a later version of xrootd)?
> >>>
> >>> Warmest regards, Matt
> >>>
-------------------------------------------------------------------------
Peter Elmer E-mail: [log in to unmask] Phone: +41 (22) 767-4644
Address: CERN Division PPE, Bat. 32 2C-14, CH-1211 Geneva 23, Switzerland
-------------------------------------------------------------------------
