uno%rand-unix@tp3.UUCP (02/23/84)
We are packaging an 11/730 running 4.1BSD with a TU80 and four RL02s. I'm setting up a backup system, and am currently planning to stack backups (using dump/restor) on a single tape (either 2400 or 3600 foot tapes). My preliminary testing has gone well. I've restored full file systems as well as individual files (using CNTL-Z under the csh when restor prompts for volume to mount then repositioning the tape and then restarting restor). I also considered doing multiple partition dumps to a single tape using dbuf, mounting the tape as a file system to do individual file restores. Worked just fine, but the system didn't like anything but 1K blocks. Still, neat if you should need a small extra file system someday, like to hear that tape drive buzzing or want to develop an empirical sense of how much buffering actually occurs during file system I/O. Everyone should try it once. Questions: 1) Does anyone have any caveats or horror stories about using multiple partition dumps to multiple files on a single tape? 2) Has anyone worked out a way to extract individual files from mag tape dbuf or dd copies of file systems with larger than 1K tape blocks? 3) Has anyone managed to get a TU80 into streaming mode? We don't seem to be able to on our 11/730, and I'd appreciate any ideas. Please reply directly to me unless you think "...that it should be seen by over 1000 of the most active UNIX people in the world...". Thanx, Somewhat actively, Stan Uno uno@RAND-UNIX (ARPA) decvax!randvax!uno (uucp)
guy@rlgvax.UUCP (Guy Harris) (03/01/84)
> 1) Does anyone have any caveats or horror stories about using multiple > partition dumps to multiple files on a single tape? One rather nasty horror story; the "dump" program determines the location of the end of the tape by dead reckoning. You tell it how long the tape is, and it counts blocks and stops when it *thinks* it's at the end. Not only is this a bit of a problem if you get tape errors (because most drives/drivers do a "write with extended interrecord gap" operation to skip the bad spot; this means not all the blocks on the tape are as long as "dump" thinks they are), but it really fouls up dumping multiple partitions to multiple files. The first dump doesn't have any trouble, but to have the second dump work you'd have to tell "dump" how long the remaining part of the tape was, etc.. The OS's handling of the end-of-tape condition (note - *not* error) should possibly be changed, and "dump" should be changed to use the end-of-tape indication to tell it when to change tapes. The DEC RSX-11 family OSes (including VMS) treat end of tape as a special condition, not an error; unfortunately, for UNIX to do this you would either have to use a new system call rather than "write" or have an "ioctl" call to test the EOT status and do that "ioctl" after *every* write. Given the RSX-11M (and probably many many other OSes) way of handling EOT, ANSI standard tapes deal with EOT by writing volume trailer records after the block that got the EOT condition. The tape foil should be placed (and usually is placed) sufficiently before the physical end of tape so that there is enough room to write the trailer labels. One does run the risk here of spinning the tape off the end of the reel, as the OS permits you to do this in order to let you write or read the trailer labels. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
lepreau@utah-cs.UUCP (Jay Lepreau) (03/03/84)
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@utah-cs, {harpo,hplabs}!utah-cs!lepreauarwhite@watmath.UUCP (Alex White) (03/05/84)
Yes, it is about time that the stupid method of dealing with end of tape on unix disappears. I have changed the drivers locally as follows On the write which passes the EOT mark, normal status is returned. i.e. the block was written out correctly. On any future write, EEOT is returned, and the block isn't written. Thus, ordinary processes which know nothing about tapes run correctly, and there is no problem; however since they call perror you get a reasonable error message when they die. However, for smart processes, you can do a MTIOCEOT which say's that you know you've hit the end of tape, but you'd like to write out trailer records. It then lets you do whatever you like; even go off the end of the tape. On reads, you always get the block, it ignores the end of tape; its up to you to verify that correct tape marks were written. Anyhow, with this actually fairly trivial change, you can now very easily change dump to correctly handle end of tape. I have fixes for mt.c and ut.c if anybody wants them; you can of course also have the fix to dump.