Due to the upcoming end-of-life of CERN CentOS 7, CTA will be migrated to Alma Linux 9, following the recommendations of the CERN Linux team. Migrating the CTA codebase from CC7 to Alma 9 presented a range of compatibility hurdles. This talk will delve into the challenges encountered and the strategies used to overcome them, including: managing version changes in vital dependencies like...
The original design of EOSCTA inherited its cache eviction mechanism — stagerrm — from CASTOR. Although similar, CTA's use-cases were not the same as CASTOR's, leading to several operational issues. This motivated the creation of a new command — evict — better adapted to modern disk buffer management in CTA.
In this talk, we will discuss the issues that we faced with stagerrm and how the...
Recent improvements to CTA repack added several new features and tools for operators. However, we were still faced with severe performance issues when repacking tapes on a very large scale. An investigation showed that this was mostly due to limitations on the CTA SchedulerDB backend, which did not scale well to performing repack on the latest generation of very high capacity tapes, which can...
The CTA software and service have been designed to match the Run-3 write performance requirements at WLCG Tier-0. The queuing system, coupled with a small SSD-based cache, has demonstrated its performance predictability over the first two years of the run.
This performance was achieved with FIFO scheduling, resulting in a pure temporal collocation on tapes, with only the legacy "storage...
CTA software development is primarily driven by the needs of the CERN experimental programme. Looking beyond Run-3, data rates are set to continue to rise exponentially into Run-4 and beyond. The CTA team are planning how to scale the software and service to meet these new challenges.
CTA is also driven by the needs of the community outside CERN. The landscape of tape archival for...
Final comments, questions and discussion.
