Last modified 12 years ago Last modified on 07/28/09 10:48:18

[part of a series of meetings]


Gerd, Tigran, Paul, Vladimir, Gene


(see Table of Contents)

Patches for 1.9.x < 3

End of life for 1.9.1 in one month.

Patch for infoProvider for StorageProtocol version property for SRM ('2.2' => '2.2.0')

Releasing 1.9.3



planned for next week.

Fix in build system.

Plans for DESY?

What are the plans for DESY to upgrade?

Plans for 1.9.4

Tape protection

Since this is a blocker patch for 1.9.4, we should try to get this in asap.

Irina has a working version. She's removing all the 'System.println()'s before submitting to RB.

Xrootd door thing

Some integration still needed for SRM and monitoring support.

Plans for gLite release

Some discussion on this.

Should do emergency release to upgrade to v1.9.1-9.

Skip 1.9.2 release and go for probably a v1.9.3 release, or maybe 1.9.4.

Items from Tier-1 support meeting

PNFS release

Build RC packages, ask Jon to upgrade, make available w/ warning to sites that they must test it before running in production.

GridFTP BNL issue

Problem with GridFTP doors becoming slow.

Gerd to send email to Pedro how to investigate this problem further. This will probably not be before Monday, though.

PNFS migration

Paul to talk with Patrick about how to clean up PNFS the errors that pnfsDump reports. A set of instructions to manually clean up PNFS so the migration can complete without errors.

Tickets that are pressing

Already covered in Tier-1 support meeting item

Review of outstanding reviews

Issue with Java 5?

Potential issue with rrd4j and compiling with Java 5?

Tier-1 list email to warn them future versions will require Java 6.

Upgrade to Berkley-DB PNFS at Fermi

The upgrade didn't happen.

Vladimir ran the same tests that Gerd did to check the PNFS vs Chimera performance. These tests show the same performance for PNFS with a PostGreSQL backend as PNFS with a Berkeley DB backend.

These results are currently not understood. When running NFS operations directly, the Berkely DB backend is noticeable faster. This suggests that there is some kind of bottleneck either within Java or within dCache code.

Vladimir is going to investigate this further.


Same time, next week:

8th July