Glossary#

Jump to: A · C · D · E · F · G · K · L · M · O · P · R · S · T · V · X

Archive ID: Identifier for the archived file version; files are treated as immutable, so each file has one Archive ID.
Archive metadata: Optional JSON provided at archive time to supply colocation hints.
ATRESYS: Automated Tape REpacking SYStem. See the tools documentation.

CASTOR: Predecessor to CTA at CERN.
Catalogue: Relational database holding the tape file namespace, permanent system data configuration, and state changes.
Ceph: Open-source distributed storage used as one of the Scheduler backends in CTA.
CTA Frontend: Component that handles workflow events from the disk buffer and requests from cta-admin.
CTA instance: A deployment of CTA.
cta-admin: Administrative CLI used by operators; issues requests to the CTA Frontend.
cta-rmcd: Remote media changer daemon process on tape servers that interacts with the media changer to mount/unmount tapes.
cta-taped: Tape daemon process on tape servers that manages tape drive interactions.

Disk instance: Disk buffer deployment (e.g., EOS or dCache) used by CTA; may serve one or multiple VOs, with CERN operating dedicated instances for large experiments (e.g., eosctaatlas) and shared instances (e.g., eosctapublic, eosctapublicdisk).

Liquibase: Database-independent change-management library used for CTA Catalogue schema migrations.
Logical library: Partition of a physical tape library (by library and drive type) that controls which drives can mount which tapes; disabling a logical library blocks new mounts on its drives.

mhVTL: Virtual tape library used in CI. See https://github.com/markh794/mhvtl.
Mount policy: Named set of parameters (e.g., priority, minimum request age) per transfer type used by the Scheduler to decide queue eligibility and trigger mounts.
Mount rule: Tuple of disk-instance, requester (user/group), mount-policy name, and activity regex that selects a specific mount policy.

Puppet: Deployment automation engine. See https://www.puppet.com/.
Protobuf: Mechanism for serializing structured data. See https://github.com/protocolbuffers/protobuf.

readtp: Operator tool to sequentially read a tape.
RelationalDB: CTA API layer for a relational database (PostgreSQL) when used as the SchedulerDB.
Repack: Copying/moving data between tapes for media refresh, replication, or migration to newer generations.
Remote Media Changer Daemon: CTA process that manages interaction with the tape-library robot arm.
RMCD: See Remote Media Changer Daemon.
rsyslog: System for log processing. See https://www.rsyslog.com/.
Rundeck: Job automation system used for operations.

Scheduler: CTA component that decides when a tape should be mounted in a drive.
SchedulerDB: Scheduler’s metadata backend (object store, file system, or relational DB) holding transient transfer metadata and changes.
SSS: Simple Shared Secret used for authentication.

Tape cartridge: Physical medium (cartridge) containing magnetic tape.
Tape daemon: Process on a tape server that schedules mounts and manages threads for tape I/O, and workflow reporting.
Tape drive: Device that reads/writes tape; a tape server may operate multiple drives.
Tape library: Physical system housing magnetic tapes and drives.
Tape mount: Assignment of a tape drive to a tape to execute queued transfers.
Tape pool: Logical collection of tapes governing file ownership and physical placement.
Tape server: Server running processes to operate a tape library, perform mounts, and participate in read/write and maintenance.
Tape slot: Slot position for a cartridge in a tape library.
Transfer request: Request that may include multiple transfer jobs (e.g., archiving with multiple copies).

Virtual Organization: Grouping of users by experiment/project; used for quotas (e.g., dedicated drives) and aggregated usage statistics.

XRootD: High-performance, scalable data access. See https://xrootd.github.io/.
XRootD SSI: XRootD plugin enabling SSS authentication; used by the CTA Frontend and being phased out in favor of gRPC.