• dCache store all TAPE REST requests in the database
  • details about staging for each file in the individual request
  • TAPE REST release operation doesn't clean transfer details from database
  • TAPE REST allows to delete request which cleans database
  • FTS transfer from tape
    • call release operation after transferring file
      • since 3.12.8 release (FTS-1913)
    • never delete request
      • no concept of "finalizing" submitted transfers
      • it is up to TAPE REST implementation in the storage to cleanup old requests
        • robust TAPE REST implementations can't expect client always cleanup request
        • even if some client call request delete there might be still situations when cleanup is not done (e.g. client prematurely terminated)
  • current dCache implementation never cleanup requests without explicit delete request call
    • TAPE REST database just grows
      • since April ATLAS staged just ~ 2M files from FZK
      • database size doesn't cause troubles immediately, because performance with 100M records is still fine
      • bigger database -> slower responses to TAPE REST operations
        • with extreme DB size this could potentiality lead to timeouts
    • dCache developers will discuss improvements
      • some kind of automatic cleanup of the old requests