Stacked dump tapes

[Jay Lepreau]

Re handling tape EOT:  I can't say I've thought this through, but it doesn't
seem so hard to me.  It sucks the way it is now and is a source of continual
frustration and occasional embarrassment.  ("Why is it wasting all that tape
on every reel?"  Response: "But you can mount one as a filesys!")

Tell me what's wrong with the following:
You can avoid a new syscall (gross!) or having to do the ioctl after every
write by setting an error, say ENOSPC, if EOT was set.  I dunno, does the
block get written out successfully anyway?  If it does, then you have to
check for errno set even if nwritten == nrequested.  Otherwise, it's
cleaner.  However, dump ought to do some stat's-- otherwise I can just
see it looping, trying to write its end-of-volume record on a full
disk filesystem when you dump to a file.

Actually, dump could even handle it with the 4.x kernel the way it is now,
since there is a "sense" ioctl, but the bit location would be grossly
device-dependent.  But one could add a simple ioctl which returned
EOT status in a standard way.

Comments?  I haven't looked at the tape drivers lately....

==============================
As for the original question, handling multiple dumps on a tape:
Fred Wilhemsen here (fmw) has hacked dump and written a filesave shell
script to handle it well.  Also, there is an undoc'ed "s <num>" option to
4.2 restore which skips <num> files on the tape before restoring.  (I don't
promise that works perfectly, as I just noticed it in the code and in the
maketape script.)  Anyway, Fred's stuff goes something like this:

--Add an "estimate" option to dump which prints out the estimated
blocks/feet/whatever but doesn't actually dump anything. This was originally
done at Purdue for an earlier version of dump. It loses in that it takes
time and the sizes could change between the estimate run and the real one.
However, that's not been a problem in practise.

--Using that, generate a shell script to actually do the dumps, giving the
appropriate "-s <feet>" option on each one.

--The script also does all sorts of useful things, such as generate tape
labels, write the reel-starting inode numbers to a file, do dumpdir's and
save in files, etc.  He uses the "save frequency" field in fstab to indicate
the dump order, as one wants to put the small filesystems first.

I expect he'd send it out if people want, but the dumps diffs might be a pain.

Jay Lepreau, lepreau at utah-cs, {harpo,hplabs}!utah-cs!lepreau