Last modified 3 weeks ago Last modified on 09/26/17 15:17:53

dCache Tier I meeting September 26th, 2017

[part of a series of meetings]

Present, IN2P3(), Sara(), Triumf(), BNL(), NDGF(Ulf), PIC(), KIT(Samuel), Fermi(), CERN()


(see box on the other side)

Site reports


Currently going quite well.

Finally got the Danish pool online.

Started -- checksum of all the files -- 2.5x106 files => 1 week to complete checksum.

When starting up -- the pool doesn't check whether the file is acceptable permissions on start-up. This is only discovered when trying to read the file (e.g. checksum )

Ulf to open a ticket.


Everything is running fine

Upgraded ATLAS instance -- everything work, but update took a long time.

Database locks

Liquibase seems to lock the entire database -- could it lock just the table it is operating on?

This would allow upgrades to happen concurrently (e.g., pinmanager, srm, spacemanager, ..)

Paul suggested placing the different services in different databases (possibly keeping them within the same DBMS system). This is now the default configuration, although many sites have the old deployment with all non-chimera databases in a single database called "srm".

GPFS logical manager issue

RT ticket 9217.

After some discussion, the desire is to have a dCache pool start so that data stored on the pool can be migrated off onto another pool.

I.e., have a pool start in "emergency mode" where it does not attempt to modify any data and allows only pool-to-pool transfers.

Pool startup

RT ticket 9214.

The fast switch from disabled to read-only is appreciated; however, the full start-up still takes a long time.

The concern is that, if they need to restart all pools then ATLAS cannot write data until the first pool has completed its start-up.

After some discussion, it seems that the pool is CPU bound, using a single thread.

Support tickets for discussion

[Items are added here automagically]


Same time, next week.