Skip to content

Eric and Vlado clarified taped's behavior regarding cleaning/checking

Imported from GitLab issue #37, 15 Dec 2016

Taped should not take any action upon startup and not try to eject a tape. When operator transitions taped from down to up, taped should promptly (that is, not waiting for some job to be scheduled) check that there is no tape in the drive. If so, taped should revert to down. The cleaner session should only be triggered when a session crashes, so that the tape can be ejected after a potential software problem. If the cleaner session fails, taped should go down.

The operator will have to verify the outcome of the check separately from the putting up of the drive (cta drive up/cta drive ls combination). This is the major change from the CASTOR environment, and come from the fact that taped is no longer a daemon.

For development: the checking that no tape is in the drive was called a probe in CASTOR and ran directly on in the mother process as opposed to all other tape drive access in the sessions. This will not be possible anymore as this will be decided by scheduling, which must be in the sub processes.