• Minimum required dCache for TAPE REST is 8.2.22
  • issues discovered with FZK recalls from tape GGUS:161903
  • dCache updated to allow path size 1024 characters long (8.2.21 supports just 255 characters)
    • additional optimization / improvements available only in 9.x branch dCache#7104
• ATLAS started deployment campaign
  • BNL mentioned dCache developers recommendation is to wait for 9.2
    • Al - performance improvements in 9.2 to support millions of transfers with TAPE REST
    • P.V. there is a limit in FTS for ~ 100k staging requests
      • I hope we should be fine also with dCache 8.2
      • no performance issues observed with FZK that use TAPE REST since April
        • staging ~ 200k files per month
    • already upgraded testbed to dCache 8.2.25 - started with TAPE REST validation
  • PIC - tape REST configured ~ a month ago
    • shared doors webdav-at1.pic.es for all WebDAV transfers (disk & tape areas)
    • manual tests works fine, but we are still trying to understand if their namespace organization is compatible with ATLAS plans for tokens / access with capabilities (storage.* scopes)
  • sufficient dCache versions for ATLAS T1 tapes
    • FZK - 8.2.22
    • NDGF-T1 - 8.2.23
    • pic - 8.2.22
    • SARA - 8.2.24
  • difference of behavior in FTS < 3.12.8 regarding the retention of staged files after they are transferred FTS-1913 (resolved)
    • new 3.12.9 release planned for first week in August
    • 3.12.8 is not going to be deployed at CERN and these FTS instances will jump directly to 3.12.9