Last modified 4 years ago Last modified on 01/06/16 15:37:01

dCache Tier I meeting January 5, 2015

[part of a series of meetings]

Present, Paul), IN2P3(), Sara(), Triumf(), BNL(), NDGF(), PIC(Marc), KIT(Xavier), Fermi(), CERN()


(see box on the other side)

Site reports


Xavier reported that, over the holiday season, dCache ran pretty well. They had only one problem: the LHCb instance suddenly stopped all recalls. Tape staging requests were suspended. Manually retrying didn't help. Xavier thinks that the pinboard said something about the age of the request was too old.

Tigran thought this could be number of retries.

Xavier tried both retry -force and failed. Neither worked. The retry command apparently succeeded, but the file immediately went into suspend. The failed command failed, returning failed; it was unclear whether this was because of a bug in poolmanager or in the web-admin.

LHCb instance runs dCache v2.13.9.

The rc ls shows the number of retries; this was at the configured to be 3.

Restarting the dCacheDomain "fixed" the problem: staging requests started to be processed.

Support 8864

Create a directory. Then manually assign these files to this directory. You must take care to increase the nlink count for the parent inode.

Tigran will update the ticket.


Some problems 28--30th December. The system became unstable.

Restarted releaved the problems for about 2 hours later but it was unstable with finally failing at 30 December.

PoolManager was not responding to admin interface.

Currently everything is working.

This dCache instance has v2.13.13 on core services, and v2.13.16 pools and some doors.

Support tickets for discussion


Proposed: same time, next week.