Skip to content

CASTOR tape scheduling responsibilities

This section only attempts to describe the responsibilities of the CASTOR tape scheduling algorithm. Implementations details are purposely avoided in order to concentrate on the goal of identifyng the scheduling equirements addressed by CASTOR.

The tape scheduling algorithm of CASTOR is implemented across three CASTOR daemons:

  • Stager daemon which is responsible for:
    • Identifying when there is either enough data or an old enough user request to warrant mounting a tape. Enough data is a well defined formula. An educated assumption is made for the amount of time it takes to mount and unmount a tape. This is converted into an equivalent ammount of stored data using the throughput of a tape drive. The expected drive efficiency is then decided and the amount of data to warrant a tape mount is therefore calculated. A user request is considered old enough to warrant a tape mount when its age reaches the maximum amount of time end users are expect to wait for their files to be retrieved.
    • Helping ensure a fair share of tape drives between the various Virtual Organisations (VOs) by not allowing more than a configured amount of on going tape mounts per tape pool and per recall group.
    • Determining the priority of tape mount requests based on the priorities of the users requestng access to files on those tapes.
  • VMGR daemon which is responsible for:
    • Choosing the next tape to be written to for a given tape pool and an initial amount of data.
    • Minimising the spread of files across tapes, or to put it another way, preserving as much as possible the natural "creation time" collocation of files.
    • Ensuring there is some randomization in the tapes chosen for writing in order to avoid unforeseen physical error loops where a particular tape is prematurely returned to a tape pool due to a fault and then immediately pulled back out again ad inifinitum.
  • VDQM daemon which is responsible for:
    • Dispatching mount requests to free and compatible tape drives.
    • Obey the laws of physics and ensure no tape is required to be in more than one tape drive at a time and that no tape drive should mount more than one tape at a time.
    • Ensuring there is some randomization in the tape drive chosen in order to evenly spread the wear and tear of tape drive usage across all compatible tape drives. Computer algorithms are naturally NOT random.
    • Implement tape mount priorities by ordering tape mounts as follows:
      1. All write mount requests before read mount requests.
      2. Higher priority tape mounts before lower priority tape mounts.
      3. FIFO order for tape mounts of the same priority
    • Reuse mounts in order to avoid uneccesary usage of the tape library grippers.
    • Enforce dedications:
      1. Tape to drive dedications to allow for "repair" work.
      2. Drive to tape/VO dedications to enforce throughput and fairness.
      3. Read-only dedications to get through urgent reads that would otherwise be starved by write mount requests.

A notable mention has to be made for the tape gateway daemon. Whilst not on the above list of daemons, the tape gateway is responible for the networked communication between the stager host and the tape centric daemons, namely the VMGR, VDQM and tape server daemons.