Last modified 12 years ago Last modified on 04/15/09 16:19:31

dCache Tier I meeting Apr 14, 2009

Present,Tigran,Paul,Owen), IN2P3(), Sara(Onno), Triumf(Simon), BNL(), NDGF(Gerd), PIC(Gerard), GridKa(), Fermi(Dmitry,Timur, Catalin), CERN()




  • Site reports
  • DTNM

Site reports


Gerd was just back from holiday so couldn't comment on any issues with dCache over the last week. However, initial investigation shows dCache is still working.


Gerard asked what is the SRM vacuuming option for? This appears to be a binary switch enabling something within the pin manager. Gerard tried to switch this option off, since the PostGreSQL database does auto-vacuuming. However, some time after this was done, he noticed high load resulting in degraded performance of SRM.

The issue was discussed however noone in dCache team fully understood the implications of switching off this option. Gerard agreed to open a ticket so the matter can be investigated further.

Gerard also reported that PIC are intending to move to 1.9.1. He was wondering if there was any migration process when upgrading the pools? (Ans: no) and whether there would be any problem switching the test-instance pool back to 1.9.0 (Ans: no).

There was also a question on how best to publish multiple SRM end-points in GLUE. Paul mentioned that there was a fundamental problem in Glue v1.3. SRM services are published as GlueService objects; however, there is no way in GLUE to link the GlueService to the corresponding SE. Because of this, WLCG have introduced a naming convention where the GlueSEUniqueID must be the FQDN of the SRM endpoint. Because of this, each SE can have (at most) one SRM end-point FQDN: any additional end-points will be ignored by FTS and GFAL (Paul believes!)

Paul and Gerard agreed to continue this discussion off-line.


Nothing new to report. Onno reported that SARA continue their preparation for a PNFS to Chimera migration.


Everything OK.


Fermi reported a performance problem; however, this was tracked down to Fermi-local binaries, involve code that only Fermi use, so of no immediate relevance to other sites.

Jon & (Catalin?) have started back-filling their batch system with dCache-loading jobs. Once (enough of?) these jobs are running, they intend to stress-test the latest version of dCache.


(via email)

Nothing to report.


Tuesday Apr 21, 2009 16:15 CEST