Last modified 11 years ago Last modified on 09/08/09 17:12:56

dCache Tier I meeting September 8th, 2009

[part of a series of meetings]

Present, IN2P3(), Sara(), Triumf(Simon), BNL (Pedro), NDGF(Gerd), PIC(Gerard), GridKa(), Fermi(), CERN()

Site reports


nothing to report.


Updated to latest Trunk version of dCache. Up to now no problems.


Things are OK.

Chimera testing

Q: How should a site clean up HSM files that have a cached copy on disk? There is a cleaner that deletes the file from disk, but then there is now no entry within the database.

Tigran: the t_locationtrash table should contain a copy for each file that has been deleted and has a copy on tape. "Copy on tape" means that there is an entry in t_location table with the location-type field set to 0.

Q: Did you run the osm2chimera.sql script. This is needed to populate the t_location table with entries describing the copies stored on tape.


To remove entries from HSM there are two options:

  1. enable an HSM cleaner. This option will be available for 1.9.5 release.
  2. write a daemon that periodically scans t_locationtrash table.

Option a. would send a remove message to an HSM-attached pool. This would invoke the HSM script with the command DELETE. When this returns successfully the t_locationtrash table entry is removed.

Option b. would allow any activity a site may need: however, the site must write the daemon to scan the t_locationtrash table, process the deleted files and remove the entry from t_locationtrash when this process has complete successfully.


Gerard is just back from vacation. dCache has been working smoothly for the last 15 days.

PIC is planning to upgrade to the 1.9.5 release in late October.

Patrick asked if PIC is planning to upgrade to an earlier version of dCache (e.g., 1.9.4-nn) prior to this. Gerard: not planning any further upgrade if it's not necessary.

As a side remark, Patrick reported that Fermi are putting more effort into porting Enstore to using the Chimera namespace.

Q: Does this mean that Fermi will be migrating from PNFS to Chimera? Patrick: we cannot answer for Fermi, but they have someone who is seriously investigating the PNFS-Chimera migration process.


Doris reported via email that they do not have anything to report.

Tape Protection

Graeme : "Tape protection from normal users is critical for ATLAS, so people need to build this into their pre-LHC start plans"

Patrick reported ATLAS' experience that is that end-users were able to trigger sufficient tape-restore activity to "melted" Castor. He is concerned that ATLAS Tier-1 centres have sufficient protection to prevent this kind of problem for when data taking starts.

Tape protection is available with the 1.9.4 release of dCache. He relayed Graeme's request that sites have tape protection in place for when data-taking starts.

As a suggestion, perhaps sites could deploy 1.9.4 on their test instances and test that the tape protection can be configured for them.

Q: can we enable this for a single VO?

Yes and no. Once tape protection is configured, it is enforced for all read requests. The tape-restore authorisation file accepts a list of DN, VOMS pairs. Either can include a wildcard. Specifying a wildcard for the DN would allow all users from the specified VO to trigger restore from tape.

Q: What if a user isn't using coming with a VOMS certificate?

If a site needs to authorise all user of a VO even when they attempt to read with a non-VOMS proxy then the site will have to specify all DNs in the tape-restore authorisation file.


already has some protection built-in in their HSM component

Pedro reported that they achieved this using a custom component. They have had some experience with a massive restore-request storm and are confident that their dCache+HPSS system will be able to handle the load, even without tape protection.

Pedro also mentioned that they have a disk buffer in front of the tape system. Patrick asked how large is this buffer? Some terabytes.


Proposed: same time, next week.