So, we all survived the Hamburg storms and the Sun dinner. Day 2 of the dCache workshop consisted of presentations about installation and configuration as well as talks about new features that should be present in future versions of dCache.

Owen Synge talked about the dCache build and testing system that he has set up. This makes the building of dCache more transparent and automated, allowing the developers more time to develop the code. I think it is this new procedure that has improved the reliability of dCache releases, as well as increasing their frequency. The testing system should also prove useful outside of DESY in order for sites to test basic functionality after installation. I've already got my hands on a beta version.

Martin Gasthuber presented recommendations for hardware setups. The message seemed to be that services should be split onto multiple nodes in order to increase performance. So far this doesn't appear to be necessary at our Tier-2s, but possibly they have not been getting stressed enough (particularly in terms of WN access to the SRMs) to develop problems.

For anyone wanting to use Quattor to configure your site, Stijn de Witt has developed the relevant templates. This is a lot of work and requires new templates to be made for each release. I think it is only worth looking at if you are really serious about using Quattor across the entire site.

I talked about monitoring dCache with MonAMI. This has proved very useful for highlighting the CLOSE_WAIT issue at Edinburgh. Hopefully we can get to the bottom of the problem by working with the dCache team next week. Some guys from SARA seemed interested in using it since they were experiencing similar issues and were already using Ganglia and Nagios for local monitoring. It would be great if we could integrate MonAMi with some of the new monitoring tools coming with dCache.

The dCache team then presented their responses to issues that had been raised during the site reports. Very useful information for anyone running dCache.


Chimera was presented. This is the replacement for PNFS, based on relation databases. It will continue to simulate the /pnfs namespace, so nothing should change for the users. However, rather than using NFS v2 they are moving to v3 and probably v4.1 (although the spec for that has still not been finalised). The dCache team appeared quite excited about using 4.1 since it has functionality that maps well onto dCache (separate control and data channels) and would have the advantage that the clients would come with future versions of the OS that dCache runs on (NFS being a standard).

Their was also some more information about ACLs and the new jpython interface to the dCache admin shell. This should improve our ability to script operations using the interface. The dCache team intend on providing some admin scripts and examples.

Overall the workshop was very interesting, lots of good stuff being presented. If there are any questions then drop me a email.