Last modified 11 years ago Last modified on 09/22/09 16:49:33

dCache Tier I meeting September 22, 2009

[part of a series of meetings]

Present, IN2P3(), Sara(Onno), Triumf(Simon), BNL(), NDGF(), PIC(), GridKa(Silke,Doris), Fermi(), CERN()


(see box on the other side)

Site reports


Last week, talked about problem with files reported "unavailable", but they were actually available and could be copied.

This was fixed. The problem turned out to be due to we introduced a non-standard configuration setting that triggered a bug in dCache. The problem was removing the "*/*"

We now have another problems. This is that our SRM is crashing. Happened in the last week. IUt happens when there's a lot of staging being done. The first time it happened, the request was to get more debugging information. The location where this information

The location of this debugging information was mailed to support@…

Simon: default pre-stage test. If you put the lifetime shorter than the system can cause memory process will be .. tmanager will hang ... all system will become stuck.

Doris: what setting caused the unavailable problem.

Transfer protocols there was a "*/*" catch all configuration. This means if no other protocols are configured, this one will trigger a bug. Suggested by Gerd.


System upgraded to 1.9.3 on Friday. One pool node got high load.

100% CPU usage. Lots of waiting IO. Memory usage is OK.

captured a picture from Ganglia.

Haven't had a chance to log into admin interface

Sysadmin did a machine reboot and then everything was OK.

The billing information doesn't show a high load for that pool.

What platform? OS / Hardware.

SL4, XFS, IBM X365.

Not submitted a ticket yet.

Old pool. In production for more than two years.

That pool was rebooted again last night.

Another problem: historical.

Didn't get get checksum enabled. Force a pool to checksum

Check the csm commands in the pool (via admin interface). One can specify all pools or just one.

If I run this command

Simon to send an email.


Ask Tigran some questions, but these are just some initial problems.

One question:

My colleges

LHCb to update the dcap client 1.9.3 two different versions: 32-bit and 64-bit. Install into the same directory. How do I respond to this problem?

Yum seems to have a bug that prevents

RPM should allow 32-bit and 64-bit

Libraries directory.

/opt/d-cache/dcap/lib /opt/d-cache/dcap/lib64


Proposed: same time, next week.