Hello, You are right I am involved in Atlas production and using dcache storage element. I thought dcache with TSM (or HSM) will be useful for babar as well. I never realised that xrootd also interfaced with mass storage system. We can try this as well. Can you point me link which gives details about it ? Do you know any group using dcache with TSM in our babar group ? Thanks, Ashok > hello Ashok, > > what is the reason for choosing dcache instead of > xrootd ? (are you involved also in LCG ?) > the latter can also be interfaced with a mass storage system. > cheers, > JY > > [log in to unmask] wrote: >> Hi Wilko, >> >> Are you using dcache xrdxp command ? Do you use dcache for storing >> the >> data ? >> >> At Uvic, we are installing dcache with tape (TSM) to store BaBaR data. >> We can copy the data to tape and access it through xrootd door. >> I am wondering how to keep bookkepping about it ? >> >> Any advise ? Do you know anybody storing BaBar data on dcache and >> accessing throuch xroot door and keeping bookkeeping of it ? >> >> Thanks, >> >> Ashok >> >> >> >>> Hello Fabrizio >>> >>> I will start testing xrootd and xrdcp again (I was gone for a couple of >>> weeks). >>> I will do some larger test with xrdcp as I would like to try using >>> it for the Babar data distribution. >>> >>> Cheers, >>> Wilko >>> >>> >>> >>> >>> >>> On Mon, 18 Jun 2007, Fabrizio Furano wrote: >>> >>> >>>> Hi all, >>>> >>>> it looks like I finished this small dev/bugfix round on XrdClient. >>>> Very >>>> few >>>> added features: >>>> - function to clean the cache forcefully >>>> - windowsize agreement between client and server in multistream mode >>>> (i.e. >>>> you only need to set your preferred WAN tcp windowsize on the server >>>> side) >>>> - TestXrdClient_read now has the --check option which does a basic >>>> correctness check on the data it receives. >>>> >>>> For the bugfix part, the most important ones are: >>>> - correct interpretation of error messages coming out as unsolicited >>>> responses to staging requests (needs validation from Andreas) >>>> - correct behavior of the cache with 'nasty' chunk requests >>>> - correct optimization of concurrent connection creations >>>> - mem corruption in creating connections in the connection manager >>>> - mem corruption in purging unused connections in the error recovery >>>> mechanism in the multistream case >>>> >>>> Right now I am finishing the tests, but everything looks fine up to >>>> now. >>>> I'd >>>> like to hear from you if you have problems with the latest version. >>>> >>>> BTW xrdcp with the latest code is scoring 6.1MB/s between PD and SLAC, >>>> against the previous 4.5-5MB/s. It would be nice to hear from you if >>>> you >>>> confirm this improvement or if it's just in my setup for some strange >>>> reason. >>>> >>>> Fabrizio >>>> >>>> >> >> >> > >