 |
 |
Hmmm, some thoughts. It would be possible to layer xrootd on top of dCache but that would mean displacing many of the things that dCache tries to do (it essentially tries to do everything that xrootd does). The simplest solution is to to do what Wisconsin did -- create symlinks with known names to dCache files when the get staged in and then just run xrootd in a normal fashion. Right now, I don't have plans to do that but if Wisconsin wants to contribute the solution we could add it to the distribution. In many ways JY is correct and that is why we are persuing an SRM interface for xrootd. That doesn't completely solve the problem but does allow for greater flexibility on what you deploy as the "back-end". Arie Shoshani, Alex Sims, and I have laid the ground work to make this happen. In the end, you can't easily mate with a system that insists on complete control of the disk cache and all the servers that have access to it. At least not without sacrificing most of the scaling and high performance that xrootd provides. That's probably not what you want to hear but, unfortunately, that's the reality. Andy On Wed, 8 Jun 2005, Jean-Yves Nief wrote: > 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 > > > >