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.