Help Me #1

[Chris Torek]

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 at umcp-cs		ARPA:	chris at mimsy.umd.edu