Last modified 7 weeks ago Last modified on 06/06/17 14:55:52

dCache Tier I meeting June 6, 2017

[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


Everything is OK at PIC.

Already set up new pools in production using 8TB disks, so 280TB each pool. Just after summer renewing (almost) the entire pool farm.

Next purchase will be about 4 PiB, with ~150 TB (not more than 200 TB) pools.

Support tickets

Can closed RT 9153 -- pinv3 table.

Limits? root defaults should be fine.


Quite a lot of trouble with new pools (new hardware). Want to ramp up the number of transfers

Previous machines 2,500 concurrent transfer tasks. On paper, new machines are 4x as big --

JVM frequently crashes with depleted threads

This is ticket RT 9203

The old pools are SL-5 and new pools are SL-6.

Tigran -- we had same issue at DESY. He will send Xavier details of the configuration DESY is using, including puppet configuration.

Performance was very bad at DESY

Interesting to see the /proc entry for the dCache process; specifically, the allowed number of threads.

Restart pool leaves children

When pool died, the migration scripts are not killed, but inherited by the init task.

ACLs with admin commands

Issue: migrated from old to new storage. Migration move (not admin, but "root"), info for migration task.

Ticket may be closed

RT 9165 may be closed

RT 8890 could Tigran check the functions -- "looks correct", Ticket may be closed.

Support tickets for discussion

[Items are added here automagically]


Proposed: same time, next week.