Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!watnot!watcgl!onfcanim!dave
From: dave@onfcanim.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: Backup of a live filesystem revisited
Message-ID: <15165@onfcanim.UUCP>
Date: Mon, 22-Dec-86 10:26:17 EST
Article-I.D.: onfcanim.15165
Posted: Mon Dec 22 10:26:17 1986
Date-Received: Tue, 23-Dec-86 02:45:01 EST
References: <4760002@hpirs.HP> <1226@ho95e.UUCP> <1392@cit-vax.Caltech.Edu>
Reply-To: dave@onfcanim.UUCP (Dave Martindale)
Organization: National Film Board / Office national du film, Montreal
Lines: 13

Yet another thing that can go wrong is this: dump reads the I-list, and
decides which files to write out.  By the time it begins dumping
a particular inode, that file has been re-written.  The file is a
large file; it has indirect blocks that have been released and re-allocated
like the rest of the blocks in the file.  Due to other filesystem activity,
different blocks got allocated for the indirect blocks this time.

When dump goes to read the indirect blocks (based on the old, obsolete
inode) it gets a block full of ASCII text or machine code or whatever
instead of disk block numbers.  When it interprets the data as block
number, it gets read errors trying to read ridiculous block numbers.
Someone seeing all those read errors is likely to abort the dump, if 
dump doesn't decide itself to give up.