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
> >
>
>
|