Backup of a live filesystem revisited

dave at onfcanim.UUCP dave at onfcanim.UUCP
Tue Dec 23 01:26:17 AEST 1986


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.



More information about the Comp.unix.wizards mailing list