End Of Tape Handling

Situation

  The current system tries to use the vendor supplied archive programs
  (dump, tar, GNU tar, cpio...) in a vanilla fashion.  GNU tar and
  modern versions of dump support end of tape detection in one way or
  another, but there's no consistent way to deal with things, and when
  the backup system was written, I don't think any of them supported
  eot detection (I don't recall when I added it to dump).
  Consequently, the backup system doesn't deal with end of tape very
  well, and doesn't support programs that do.

  There are two ways that we might support end of tape handling.  One
  would be to leave it up to the archive programs, and simply try to
  intercept and interpret their requests for new tapes by "doing the
  right thing" and then telling them to continue.  This means that
  we'd have to handle them on a case by case basis, though there are a
  few general support things that we could add that would benefit all
  of them.

  The alternative is to use a scheme that I learned from Frank Kardel
  of the University of Erlangen, Germany at a USENIX conference
  several years ago, and which was later implemented in the Columbia
  University DeeJay backup system.  Rather than leaving end of tape
  handling up to the archive program, have them direct their output to
  a tape program which is responsible for media initialization and
  identification, error handling, and end of tape detection and
  recovery.  This makes a lot of sense for several reasons.  

  First and foremost, most archive programs don't deal with eot at
  all, and this solves that nicely without requiring changes in the
  archive programs.

  Second, eot handling is hard - different devices report
  EOT differently, and this is complicated by operating system
  differences.  Does the first write where eot is detected result in
  a partially written block, or no block at all?  Do you get a ENOSPC,
  or a write error?  It seems like it would be easier to ensure
  successful handling of eot in a single program than in trying to get
  it right on several.

  Third, there are icky problems when you try to implement eot
  handling with fast rmt support in dump (the rmt end requires special
  tweaking so that it won't write blocks past where eot was detected,
  else things get out of synch between dump, rmt and what was written
  to the tape).

  Finally, you want this to be integrated tightly with the media
  control in the backup system - device locking, tape identification,
  free tape management, and so on.

Desired Features

  There are several options when you hit end of tape:

	- give up and die

	- roll to a tape in a different tape drive on the same host 

	- roll to a tape in a drive on a different host

	- roll to a tape in the current drive (stacker, jukebox) on
	  this host

Implementation

  Change the backup system so that the archive program always dumps to
  stdout.