Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!floyd!harpo!utah-cs!lepreau From: lepreau@utah-cs.UUCP (Jay Lepreau) Newsgroups: net.unix,net.unix-wizards Subject: Re: Stacked dump tapes Message-ID: <2555@utah-cs.UUCP> Date: Sat, 3-Mar-84 02:55:06 EST Article-I.D.: utah-cs.2555 Posted: Sat Mar 3 02:55:06 1984 Date-Received: Sun, 4-Mar-84 02:16:55 EST References: <16873@sri-arpa.UUCP> rlgvax.1762 Lines: 46 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" option to 4.2 restore which skips 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 " 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!lepreau