Skip to content

Drive Dedications

During the CTA developer meeting of Wednesday 10 August 2016, we discussed the use-cases for tape drive dedications.

Daniele's first idea of CTA dedications

This concept came out of the early requirements discussions at the beginning of 2016.

Dedication Type

In CTA one can set a drive to perform read-only, write-only, or read-write sessions.

Bi-directional VID Dedication

In CTA one can dedicate a drive to a specific tape and at the same time that same tape to that same drive. This ensures that that tape can only be mounted on that drive and that that drive can only mount that tape.

Tag Dedication

In CTA one can dedicate a drive to a "tag" which is basically an arbitrary string. This ensures that the drive will take only admin jobs (such as repack and verify) labelled with that same tag. This concept replaces and enhances the "self-dedication" of CASTOR.

Compulsory Parameters for Drive Dedications

  • from: date-time corresponding to the beginning of dedication validity
  • until: date-time corresponding to the end of dedication validity
  • comment: a comment is always required to explain precisely what the dedication is for

Notes

  • When listing dedications, only the ones that did not expire yet will be displayed. The ones which have expired ("until" date-time passed) will be automatically pruned.
  • Updating a dedication for a drive will always succeed. No need to remove the outstanding one beforehand.
  • When a tapeserver queries the catalogue for its dedication, the catalogue will return it only if the "from" date has passed, and the "until" date hasn't passed yet (note the difference with listing).

Use-cases

  • Labeling, repacking or verification of a single tape in a specific drive (VID dedication)
  • Labeling, repacking or verification of a set of tapes on a specific set of drives (TAG dedication)
  • Setting a set of drives and source and another set as destination (to resolve situations in which one way is more urgent than the other)
  • And most importantly any unforeseeable situations in which the CTA scheduling may not be of help

Eric pointed out that we should revisit the concept of dedications as they are CASTOR legacy

In fact most of the original requirements can be addressed differently in CTA. Some of the use-cases and their corresponding proposed high-level solutions are:

USE-CASE: An admin (or potentially also user) job of a specific set of tapes that should run on a specific set of drives

SOLUTION: Introduce a "TAG" concept similar to (but completely independent from) CTA logical libraries, where the set of drives is tagged using a string, and the same string is used to tag the set of tapes to mounted on them. Tapes with tag X will only be mountable on drives with tag X, drives with tag X can only mount tapes with tag X; similarly tapes with no tag can only be mounted on drives with no tag, and drives with no tag can only mount tapes with no tag. One additional idea: w.r.t. logical libraries, tags have a temporary connotation and could therefore have a start and end time of their validity.

USE-CASE: A specific repack/label/verify job needs to be run on a specific drive.

SOLUTION: Enhance the corresponding admin request with a parameter specifying the desired drive to accomplish the operation. This is a one-off dedication that expires as soon as the job is done.

USE-CASE: A tape repair/extract operation requires the tape to be accessible by an admin but not by a user

SOLUTION: Introduce a new tape state such as DISABLED_FOR_USERS that will allow, repack/verify/label commands issued by admins but avoid all archivals and retrievals

USE-CASE Some tape drives we are using are not covered by the maintenance (the reason is to save money during the long LHC shutdown period when smaller number of drives is sufficient). Occasionaly, some of those tape drives show various problems and as IBM will not replace them, they are not suitable for writing any data. However, they are good enough for reading. In CASTOR mode=0 dedication is used to keep those drives still in production.

SOLUTION: ???

Eric further clarified the use cases of Jean-François

When dealing with read errors (from user reads, repack or verification), Jean-François first runs a verification on the first offending file of the tape. If this fails, then another drive is used, so we would need to forbid the verification on the drive. On the opposite, if the read succeeds, he will then run the repack on the same drive. In addition, there might be several classes of drives (like new hardware revision, which succeeds where the previous batch fails). So he also needs to choose the drive from a list of several drives.

The current implementation of this decision making is achieved by first picking by hand an idle drive (or making it idle by interrupting a verification session). Then the drive is dedicated to the forthcoming session into TOMS. The session is then run and the deication is removed by hand.

A proposed replacement for this logic would be to add a positive or negative requirement list (1+) of drives to the verification/repack request. This would cover the same use case with less manual intervention (no need to choose the drive by hand, and no need for tedious dedication operations).