dCache Tier I meeting November 15, 2011

[part of a series of meetings]

Present

dCache.org(Tigran, Tanja, Paul), IN2P3(Nicolous), Sara(Ron), Triumf(Simon), PIC(Gerard), GridKa(Doris)

Agenda

(see box on the other side)

Site reports

GridKa

Doris said that apart from some problems with the update of the ATLAS instance to 1.9.12, things are fine.

SARA

Ron reported that everything is going pretty well.

There are two issues.

Problems staging

Ron has a problem where staging requests seems to hang. What happens is the pool-manager sends a stage request to a pool but that pool is completely full with pinned files.

This looks like a problem with the cost module.

Ron has opened a support ticket about this.

Username and password for WebDAV

SARA have deployed dCache v2.0.0 on their test instance. They are using gPlazma 2.

WebDAV with username+pw authentication doesn't work.

Everything else is working fine, including plain FTP with username +pw authentication.

Ron has opened a support ticket about this.

PIC

Gerard had no new issues to report. They are still struggling with the existing issues.

Triumf

Simon reported that Triumf had some problems last Tuesday. The billing service hung, seemingly due to a problem with PostgreSQL server. The billing domain and PostgreSQL server are running on the same host and this host showed high percentage of CPU time in IO-WAIT.

The unusual part is that the http and info domains were also not responding, despite the fact that these machines are hosted on a different node that the billing domain and PostgreSQL server.

Simon disabled the billing option and restarted the domains. This solved the problem for now.

Simon will open a ticket so dCache can capture the information and investigate further.

IN2P3

Nicolas reported that everything is OK. He had two questions:

'regular' queue

In the past (1.9.5) IN2P3 pools had a 'gridftp' and 'dcap' queues. These are now replaced with one 'regular' queue. Is it still possible to separate queuing between the different protocols?

Yes, you can still do this.

What has changed is the pool's behaviour if a request had no queue specified, or if that queue wasn't known. Previous (1.9.5) behaviour was that the first defined queue was used as a default queue. With 1.9.12 there is now a 'regular' queue that is always created. Requests with an unknown queue name or that don't have a queue are sent to this 'regular' queue.

Nicolas is going to submit a ticket so dCache can advise how to configure their pools and so we can update our documentation.

Deleting HSM files

With PNFS, HSM-stored files that have been deleted may be identified by scanning PNFS' trash directory. This is how IN2P3 would clean up deleted HSM-stored files: they would periodically scan this table for files and issue commands to the HSM.

What are the options with Chimera?

You have two possibilities: look in trash table or enable the HSMCleaner.

The trash table in Chimera acts in a similar fashion to the trash directories in PNFS. Periodically scanning these for deleted files will allow a site to remove files from the HSM.

There is a dCache service 'cleaner' that periodically scans for deleted HSM-stored files and sends commands to a pool so that the HSM script is called with the 'delete' command. This command will receive the same arguments as if it was a stage request.

Support tickets for discussion

[Items are added here automagically]

DTNM

Same time, next week.