wiki:developers-meeting-20090303
Last modified 12 years ago Last modified on 03/03/09 17:48:47

dCache Tier I meeting Mar 03, 2009

Present

dCache.org(Tigran, Paul), IN2P3(), Sara(), Triumf(Simon), BNL(), NDGF(), PIC(Gerard), GridKa(), Fermi(Timur), CERN(Andrea, Flavia)

Apologies

IN2P3, BNL

Agenda

  • Site reports
  • New info provider & how to configure it

Site reports

Triumf

Everything OK

PIC

Everything OK

FZK

Everything normal.

The scheduled down-time for the ATLAS split is next week. This is where nodes of the current FZK instance are to be split off to form an independent dCache instance for ATLAS.

CERN

Andrea: nothing to report.

Flavia brought up an issue with SRM client tools (supplied with dCache) when connecting to Castor. The issue is that srm-cp fails with Castor when the "internal" GridFTP server is used---when using the "external" GridFTP server it works.

Initially this was reported as the client (dCache's srm-cp) making two connections to Castor with the TURL becoming invalid after the first connection disconnects.

Timur corrected this. The srm-cp command only makes a single connection to Castor. The GridFTP server advertises a checksumming ability. The srm-cp comment attempts to utilise this but the functionality seems problematic and fails. Subsequent to the checksum failing, srm-cp attempts to continue only to discover the TURL is now invalid.

Flavia asked if it were possible to avoid the checksum transfer stage? Timur said it was; the server should refrain from publishing its support for the checksum extension: the checksum stage is only undertaken if the server advertises its support.

Flavia would take this issue back to the Castor team for further investigation; it seems that the Bestman client also show the same problems and there was a similar issue with StoRM.

Fermi

Timur reported that he's not heard of any problems since back from holiday.

IN2P3 (via email)

no issues

New info provider

Gerard ask about the new info provider and how to configure it.

Paul replied saying that the new info provider's configuration is in /opt/d-cache/etc/glue-1.3.xml and that there's documentation on how to configure it called README-GLUE (/opt/d-cache/share/doc/README-GLUE).

There's a known issue with one of the deprecated fields (GlueSAStateAvailableSpace, GlueSAStateUsedSpace) due to an overflow bug in xsltproc. If a site is big enough, this may result in a negative integer or a floating-point number (depending on xsltproc version) being emitted in the LDIF instead of the correct integer value. The solution is either not to publish these attributes or to use a different XSLT processor. Future versions of dCache will use Saxon instead of xsltproc.

Doris asked about whether the poolgroup space information will be included in the old info-provider. Paul replied that we anticipate people moving to the new info-service based info-provider and that bug-fixes would be focused on that version.

Flavia asked about an info provider that supports the Glue-1.3 installed capacity document so it can be verified. The code should be ready by 13th March but that deploying it may take a little longer (and isn't really under his control) --- but hopefully something will be possible "soon".

DTNM

Same time, next week: 16:15 ECT, Tuesday 10th March