Last modified 3 months ago Last modified on 07/03/18 15:05:50

dCache Tier I meeting July 2nd, 2018

[part of a series of meetings]

Present, Tigran), IN2P3(), Sara(), Triumf(), BNL(), NDGF(Dmytro, Christian), PIC(Elena), KIT(Xavier), Fermi(), CERN()


(see box on the other side)

Site reports


Everything is going well.

Update the ticket with the problems .. token was full.

Update pending that will fix this issue.


Generally things are going well.

Last week there was a problem: run virtual machines that provides endpoint. One physical machine had network interruptions.

After 3 minutes, the network came back up but dCache did not recover. There was a stack-trace.


Running fine for the past few weeks.

Ticket network issues RT ticket

This ticket is similar to what NDGF just reported.

Ticket network issues RT ticket

Feature request, asking for recovering from old db entries in the background, while starting up.

Still experimenting upgrade to 3.2.

Splitting tables into separate databases

Would like to split up tables as part of the 3.2 upgrade.

Dump original database and copy with remote database -- way too slow.

Dump individual tables and restore into individual tables -- lost tables.

Let dCache create databases and then copied the content -- this has order dependency issues.

Final option (not yet tested) is to restore original database several times (once for each database) and simply drop the tables in the databases that should not be there. This has the disadvantage in disk usage, but should be a robust procedure.

Tigran investigated another option: the CREATE DATABASE ... TEMPLATE.. command. This has a limitation that no other session may use the template database concurrently, but that shouldn't be a problem during down-time.

Support tickets for discussion

[Items are added here automagically]


As both Tigran and Paul will be at CHEP, the next meeting will be at the same time, in two weeks time (2018-07-17).