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