 |
 |
Hi Pablo, I see the usual points which make a site choose to use dCache. But among those the ones you cite are not present. From what I know and see, there is no tech argument to get to that conclusion, and from a pure tech view, you'd choose much differently. This is even more true since you are speaking about hundreds of terabytes. The design choices of the xrootd system were made with a much higher scale and performance level in mind. These are common misconceptions about the xrootd system, some of which might have been true years ago (e.g. srm), but not now for sure. You just have to do some things in a different way, but not too much. Anyway, the original tech point was to see if there are differences in the proof performance between the two data systems. Proof is a very particular tool, so this remains a strong curiosity for me. If you can do something, please tell it to me. Fabrizio Pablo Fernandez ha scritto: > Hi Fabrizio, > > I think (and I won't be wrong) you can have better performance with native > xrootd (since you forget about other elements slowing down the system). Maybe > for some Tier3 that would be the case (those far away from it's Tier2), but > at least for us it's not realistic. We're speaking of hundreds of Terabytes > and many access methods (srm, gsiftp...) and I don't think a native xrootd > cluster is about that. > > Regards, > Pablo > > > > On Wednesday 20 February 2008 13:27, Fabrizio Furano wrote: >> Hi Pablo, >> >> I see your point. I was mentioning the orthodox xrootd anyway, not the >> xrootd door, which from my point of view is just an emulation. After >> all, this is the xrootd mailing list :-D >> >> For lustre I am not an expert, from a pure functional standpoint you >> can put an xrootd server exporting the lustre mountpoints I guess. In >> that case you will not go beyond the lustre performance of course. >> >> Fabrizio >> >> Pablo Fernandez ha scritto: >>> Thanks! >>> >>> Unfortunately the xrootd protocol does not work as expected in dcache. >>> The idea was to use a conventional SE to store all the data for Tier2 and >>> also serve files to the Tier3... I don't know if Lustre implements an >>> xrootd door as well, maybe in a few months I'll try that. >>> >>> BR/Pablo >>> >>> On Wednesday 20 February 2008 11:40, Fabrizio Furano wrote: >>>> Hi Pablo, >>>> >>>> that's very interesting, and I agree completely with your conclusion, >>>> i.e. in most cases the lan data access is more efficient and scales >>>> better with respect to local disk access. Many times this is not very >>>> well understood by people, always striving to keep local files at any >>>> cost. >>>> >>>> It would be very interesting to have a comparison between the >>>> performance in proof between a dcache storage and an analogous xrootd >>>> storage, which is the default solution for that. With the same pool of >>>> workers of course. >>>> >>>> From what I've understood, dcache uses a read ahead mechanism (at the >>>> client side), while xrootd uses a scheme which is mixed with informed >>>> async prefetching. >>>> >>>> Fabrizio >>>> >>>> Pablo Fernandez ha scritto: >>>>> Hi all, >>>>> >>>>> I would like to share with you some information about my testings of >>>>> performance in Proof with different storage schemas. >>>>> >>>>> http://root.cern.ch/phpBB2/viewtopic.php?t=6236 >>>>> >>>>> I have translated this topic to the Proof Forum since seems to me more >>>>> Proof-related than just xrootd, I hope you don't mind. >>>>> >>>>> BR/Pablo >