Last modified 11 years ago Last modified on 04/07/10 18:14:18

[part of a series of meetings]


Timur, Vijay; Tigran, Paul, Owen, Irina, Tanja, Gene, Dmitry.


[see box on the right-hand side]


Up to two minutes (uninterrupted) per person where they can answer two questions:

  • What I did last week (since the last meeting),
  • What I plan to do in the next week.

No questions until we get through everyone :)

Tigran: mostly made up dcap, xroot (native + dCache), NFS; also Kerberos stuff for NFS.

What's the fastest protocol? NFS or xrootd, depends on application.

Paul: Wuppetal work

Owen: ETICs. New dcap release, release for EPEL as well as VDT. Several requests for Solaris dcap packages.

Irina: tested SRM space manager in 1.9.5-16 and 1.9.5-17. Maybe have questions for Timur about this later.

Tanya: tickets and progress on (pool) request queue rewrite.

Timur: Off all of last week; this week started on how to integrate latest SRM with Terracotta; committed patch dcap and gridftp doors using space manager whole authorisation object.

Vijay: busy with enstore upgrade; make sure PNFS upgrade works OK. Build PNFS for the specific PostGreSQL version. "dCache admin for the week". Got feedback on enstore patches and will work on the suggestions.

Plans for patch-releases

Should we make a new patch release?

Nothing urgent.

Trunk activity

Progress with new features...

Since Timur did the change in space-manager.

Can now commit the patch that (gsi-)dcap understands multiple roles. This wasn't committed because the rest of dCache didn't understand the multiple roles.

Currently convert AuthRecord? to Subject before The ACL module deals with this.

Issues from yesterday's Tier-1 meeting

BNL and small files: nobody knows what's causing the problem.

More discussion is that files

Triumf and PIC observe that files are not in the space manager

storage-info of the file says the file was

ATLAS writing with the token.

If the directory into which the file was written then poolmanager would include the namespace-derived token. Could we check whether this is happening?

FZK have reported this too.

It seems the pool is a member of linkgroup that is not selected otherwise.

Looks like it is always ATLAS transfers that suffer from this problems.

More investigation is needed.

FZK have a GGUS tickets about this, but they need to investigated.

Files are in dCache and can be read, but dCache claims they are not in a space token.

Pool sends "file removed" event: space-manager sees this event and removes the record. Perhaps keeping the record.

Lets first confirm that the file was actually written with space-manager.

PIC script

Dmitry has finished the recovery script. Currently testing it before shipping it. Script uses a mapping

storage-info doesn't give the right space-token for a file.

However, for PIC specific space tokens use specific directories, so this simplies the process.

Getting space-token from PNFS will give wrong information. Would need to get the storage-info from the pool for accurate information.

Can I get this on-pool-stored information from the admin interface? Nope.

Startup of Terracotta with new config system

I looks at the current configuration.

Not do something specific to

In addition to "services" in node-config ...

Continue discussion on mailing list.

Should be on-off switch.

Should we delay release until new documentation

Would be nice.

Should be a priority.

Should be in book?

Should have a single place.

New configuration system will be presented at Wuppetal; take that work and put it into Book/wiki.

Come back to this topic in two weeks time.

Good if we change something, we should delay release if it's not documented.

Lattice-QCD usage-case

Files removed from pools automatically from volatile pools, remove from name-space when deleted from pools.

Mostly we have it already: pools can enable.

Don't know how to write into

Option in pool: every time you remove a cached file, tell pnfs-manager, if last option, to remove it.

Tigran: will look into this.

LSF=volatile: makes files cached and removed automatically. Remove last copy from disk ... could be an additional switch somewhere.

They run 1.9.5-8 in production.

Pin manager

We noticed that, at DESY, (by mistake) forgot to switch on pin-manager and were surprised that they cannot read the file.

Can we proceed with the read if the pin failed.

prepareToGet without specific duration then, if the file is on-disk then don't pin.

Check if file is pinned may be more expensive than always creating

Pins don't lock the file: if a file is deleted (in namespace) then the file will be deleted.

Food for thought.

The DESY/Tier-2 usage-case: doesn't need pinning for files.

Have Storage-info in pin-manager or you cannot pin the file.

srmPrepareToGet with- and without- lifetime. For requests without a lifetime SRM should do a best-effort.

Would like decent error messages.

Outstanding RT Tickets

[This is an auto-generated item. Don't add items here directly]

Review of RB requests


Timur's questions.

Numerical UID, GID


GSI: primary LDAP: primary group in NIS system

Pinning a file: pin PNFS-ID of the file of the file to be pinned.

Why do we need a set-UID and set-GID? Unnecessary if using ACLs.

Do we allow manipulation of ACLs based on end-user credentials (DNs, etc)? This is an important question.

We need to agree on the paper as-is.

Continuation of discussion on mailing list and during the next meeting in a weeks time.


Same time, next week.