Hi Chris,
That seems like an ugly solution to me as then the scaling would still
be tied to the scaling of dCache. (And a simple file open would go through
two systems, with potentially two sets of problems to debug.) The solution
we've proposed a couple of times (relative to any system which wants to do
cache management) is that it simply expose the file name space on the disks.
Then xrootd just looks there. As I understood it, this is what Dan Bradley was
doing in Madison to use xrootd/olbd to serve the data imported via SRM into
dCache. He just put in the soft links by hand, but presumably one could do
better than that.
Pete
On Wed, Jun 08, 2005 at 05:35:28PM +0100, Brew, CAJ (Chris) wrote:
> Hi Jean-Yves,
>
> I think the dCache-xrootd coupling could be made close enough that the
> extra overhead whould be minimal. I.e. the xrootd OFS and OSS layers
> would be replaced by a shlib that talks natively to the dCache server on
> the "door" and would stream the data straight out of dCache to the
> client. I think that's how it offers gsiftp access.
>
> Yours,
> Chris.
>
> > -----Original Message-----
> > From: Jean-Yves Nief [mailto:[log in to unmask]]
> > Sent: 08 June 2005 16:25
> > To: [log in to unmask]
> > Cc: Brew, CAJ (Chris)
> > Subject: Re: xrootd and dCache
> >
> > I forgot to say that one solution to your problem would be to
> > have a SRM
> > interface to xrootd, so each sites can choose to install xrootd or
> > dCache or NFS etc...
> >
> > Jean-Yves Nief wrote:
> >
> > > hello Chris,
> > >
> > > Brew, CAJ (Chris) wrote:
> > >
> > >> Hi,
> > >>
> > >> It's loooking likely that dCache is going to be widely deployed
> > >> certainly in the UK and probably across LCG and I was
> > thinking about how
> > >> this could be integrated with the xrootd deployment we
> > have for use by
> > >> babar.
> > >>
> > >> I can think of two (probably) fairly simple things that
> > would be useful.
> > >>
> > >> 1) Enabling the dcap protocol in the KanAccess.cfg file.
> > As far as I
> > >> know the dCache protocol dcap is built into root in the
> > same way that
> > >> the xrootd protocol now is so if we can build file urls
> > that start with
> > >> dcap:// or dcache:// we could access files directly from dcache.
> > >>
> > >> 2) Adding an xrootd door to dCache. This is obviously more
> > complex but I
> > >> guess it would just mean replacing the ofs layer with
> > something that
> > >> speaks to dCache rather than the filesystem. This would
> > mean you could
> > >> get all the benefits of the xrootd protocol, scaling,
> > redirection, load
> > >> balancing, fault tolerance, proxies, etc. with a dCache backend.
> > >>
> > >> I know the second one has been discussed but are there any plans to
> > >> implement it?
> > >
> > > are those people proposing that solution (xrootd over dcache over
> > > local filesystem) serious ?
> > > it should be one or an other but not the two of them on top of each
> > > other because there will a lot of overhead for no real gain.
> > > cheers,
> > > JY
> > >
> >
> >
-------------------------------------------------------------------------
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
-------------------------------------------------------------------------
