-- JamieShiers - 22 Jan 2008


  1. Consistent use of GOCDB/CIC portal for announcing DB service interventions - a further reminder has been sent.
  2. ATLAS streaming problems - was this logged / reported through to dashboards? Alarmed? - Follow-up in progress.
  3. Lack of metrics for February CCRC'08 run - to be discussed and agreed at Jan 28 CCRC / Jan 29 MB.


  1. It would be desirable to allow the user to specify a space-token on SRM.prepareToGet – this makes Castor’s pool selection algorithm more efficient. Currently the user may only specify a token on SRM.prepareToPut (i.e. the destination) in the FTS job.
  2. SRM Copy between mixed SRM v1 / v2 sites does not seem to be reliable. FTS sets the PERMANENT flag in the SRM copy request, but this does not always seem to be propagated by the SRM running the copy; this requires some investigation between FTS and the SRM vendors (specifically dCache). The problem is fixed in dCache 1.8.0-12 (patch 1 + patch 2).
  3. NDGF have been working with DESY on gridFTP2 support for dCache – this substantially improves the performance when using FTS in URLCOPY mode. NDGF also have patches to the VDT gridFTP client (used by FTS) to allow it to use the gridFTP2 protocol. We should investigate the possibility of getting those patches into the main VDT release used by gLite.


  1. Patch 1641 might not make it through cert/pps in time for wide-spread deployment. 23/01/08 - certified: will move to PPS tomorrow


  1. bulk srmLs and srmRm requests - performance and scalability concerns. ATLAS expects to delete 100k files per week and T1 during data taking
  2. problem of choosing the correct WAN/LAN pool while performing a BringOnline operation in dCache.
    Impact - reprocessing from tape will be affected
  3. PrepareToGet requests with/without tokens: follow-up on proposal from Flavia/Maarten
  4. Various problems with srmCopy with srm v2.2
    dCache developers recommend to leave FTS channels configured in srmcopy mode because of performance issues. There will be no difference between urlcopy and srmcopy only when clients will be able to fully exploit the features of GridFTP2.
  5. Sites have been asked to publish specific information about the size of spaces. (Or is this a site issue?)
  6. When we talked about read/write permissions for dCache pools, it was mentioned that each user can read from those pools and that if a user wants to copy a file to her own Tier-3 disk area dCache will realise that this cannot be done from this LAN pool and first copy to a WAN pool from where this is possible. But this could be very dangerous because this would allow any user to copy files from tape at any dCache T1. Is there a way to avoid this?
    A more general question is that no ACLs are foreseen on spaces for dCache. A reserved space can be used by any user provided that he/she can write in the path where the file is and that there are pools allocated to that space.


  1. On-going service reliability concerns and medium-term (if that is the right term for immediately after the February run of CCRC'08) support concerns.
Edit | Attach | Watch | Print version | History: r13 | r10 < r9 < r8 < r7 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r8 - 2008-01-29 - FlaviaDonno
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    LCG All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2022 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback