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