cottrell@NBS-VMS.ARPA (COTTRELL, JAMES) (11/02/85)
/* Dump/Restore wants you to mount the last tape first when restoring selective files. Supposedly it's faster. Why? jim cottrell@nbs */ ------
chris@umcp-cs.UUCP (Chris Torek) (11/03/85)
Why mount dump tapes in reverse order? The answer depends on the
format of these tapes. Each tape starts with a new file, each new
file starts with a special record containing (among other things)
the inode number of the first file on the tape, and dump writes
things in monotonically increasing order of inodes. (The first
tape actually starts with a different special record, then lots of
bitmaps and things, but this is irrelevant to the `faster' reasoning.)
[TeX notation key: \cal => calligraphic font, for set names.]
Given a set of inodes on tapes, and a set {\cal I} of inodes to be
restored, restore can look at this special record and determine
whether the tape can possibly hold any of the `interesting' inodes
(inodes in set {\cal I}). Specifically, let i be the first inode
on this tape, and let m be max(\cal {I}). If i > m, no `interesting'
inodes are on this or any later tape---in fact, restore is also
smart enough to stop once it reaches an inode > m in the middle of
the tape. If i < m, no `interesting' inodes are on any previous
tape, but nothing has been determined about the current tape.
Suppose that you mount the last tape first. Either it contains
some `interesting' inodes, in which case the tape must be read no
matter what, or it does not, in which case restore will stop after
reading just the first record.
Now suppose that you mount the first tape first. All restore can
tell by the inode number is that the `interesting' inodes are on
this or a later tape, so it must read the entire tape.
If all the files are on the first tape, you will end up winning in
the latter case. But if no files are on the first tape, or only
part of the first tape need be read to get all the `interesting'
files on that tape, the former case wins.
Of course, the fastest way is to know exactly which tapes contain
interesting inodes, and to mount only those tapes, in reverse order.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP: seismo!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.eduhedrick@topaz.RUTGERS.EDU (Charles Hedrick) (11/03/85)
When we are doing dumps, we write on each tape the inode number of the first inode on that tape. Dump does print this information. Then when you do the restore (I assume you are doing "restore i"), turn on verbose mode. "ls" will show you the inode numbers of the files to be restored. Given that, and the inode numbers written on the tapes, you will know exactly which reels to mount.
zimmerm@ccvaxa.UUCP (11/07/85)
It is only faster if the dump has created a very large table on the first tape which diminishes the amount of tape left for the dumped info itself. If this si the case then the odds are better that the info you want is on the second (third) tape. We never follow the last tape first suggestion and do just fine. I tried it in the past and it generally took longer. Bruce Zimmerman Gould CSD-Urbana Urbana, Ill. !ihnp4!uiucdcs!ccvaxa!zimmerm
jsdy@hadron.UUCP (Joseph S. D. Yao) (11/17/85)
In article <2720@brl-tgr.ARPA> cottrell@NBS-VMS.ARPA (COTTRELL, JAMES) writes: >Dump/Restore wants you to mount the last tape first when restoring >selective files. Supposedly it's faster. Why? I've tried it both ways, under BSD4.X. When I mounted the first tape, it dumbly went through the whole tape set, searching for the inodes. When I mounted the last tape, it stopped, thought a moment, and then asked me to put on the right tape! _I_ don't know why! -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}
tim@ISM780B.UUCP (11/21/85)
I think it's like this: Each tape has at the start a list of inodes that were to be backed up when that tape was mounted, followed by as many files as would fit. If you are trying to restore the file with, say, inode 279, if you put on any tape before the correct one, it can look at the header, and see that inode 279 is one this tape OR A LATER TAPE. It has to search the tape to see if it is indeed on that tape. If you put on a tape that is AFTER the correct tape, it can look and see immediately that it is not on this tape or any later tape. Hence it is faster to search backwards. At least, that is how some backup systems work. I don't know any particulars about bsd. Tim Smith ihnp4!cithep!tim ima!ism780!tim
jsdy@hadron.UUCP (Joseph S. D. Yao) (11/28/85)
Thanks to all who have reminded me (in response to my response
to cottrell's request for info) that each file dumped has the
inode number in the on-tape file header, and the inodes are
written out in ascending numberical order, so reading the first
header on each tape tells you whether the inode is there or not.
I don't need any more reminders. If I'd devoted any processor
power to it, I'd ha' realised it sooner, rather than just not
caring. ;-)
--
Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}