Last modified 12 years ago Last modified on 08/18/09 16:57:08

dCache Tier I meeting August 11, 2009

[part of a series of meetings]

Present, Owen, Paul), IN2P3(), Sara(), Triumf(Simon), BNL(), NDGF(Mattias), PIC(Gerard), GridKa(), Fermi(), CERN()




(see box on the other side)

Site reports


Simon is just back from vacation. He reports that dCache has been working OK for the past month.

Simon is planning on upgrading to dCache v1.9.3 and asked who is running 1.9.3 so has experience with it? Gerd said he thought SARA are running 1.9.3. NDGF have run 1.9.3 in production for some time, but are now running a 1.9.4 (with some aspects of 1.9.5).


Things running fine at PIC.

Gerard reported that he has noticed some files in a strange pinning state. He opened a ticket about this yesterday and was wondering if there has been any activity. Owen reported that he's searched for related tickets: those involving pinning and has found some. Gerd reported that Fermi are working on the pinning manager; they may be intending to fix this problem as part of that work.

The ticket will be brought up at tomorrow's dCache developers' meeting.


Things are "interesting", but mostly not dCache's fault.

It seems that some components of dCache are unhappy if you shut down the database back-end (e.g., PostGreSQL) and do not recover when the database comes back online.

One example is the Chimera cleaner. It doesn't recover when the database comes back up; instead, it goes into an infinite loop. Gerd has submitted a ticket about this issue.

Mattias reported that the SRM seems to suffer from the same problem: it doesn't recover from a database restart. He's not yet submitted a support ticket describing this problem.

We took a quick survey of sites asking: how important the ability for dCache to recover from a temporary interruption to a database service without manual intervention. Gerard considered this feature important, but not extremely so.


Proposed: same time, next week.