Hi, This pops up every few weeks here on the list, its very simple: you are backing up an active filesystem with a tool designed primary for backing up filesystems mounted read-only. what happens is: dump first reads in the directory and filepositions on the disk(Pass I and II) then in pass III .... it reads from these stored places the information contained in these dirs and files. Now between mapping dirs and dumping a file was deleted or something and the corresponding blocks where freed and reused for another file. at this point dump thinks the block contains structural information, but in reality it contains data. so dump interprets more or less random data as block and sector-adresses. these adresses will most likely be rubish and way out of the limits of the disk. the result are the seek-errors you see. At this seems not too problematic, only the corresponding file should be rubish in your dump. But if you are unlucky these errors lead to completly unusable dumps.
This had been widely discussed earlier this year, if you are interested in more details, read the archives. The topic why it came up was linux-dump and linus thorvalds advise not to use it with kernels > 2.4.x. have a nice day Christoph Paul Lussier schrieb: > > In a message dated: Fri, 14 Dec 2001 09:29:54 GMT > "Thomas Robinson" said: > > >Hi, > > > >Has anyone seen or hear of this problem. > > Ayup, I get it all the time. I have no idea what the problem is > though. It seems to come and go sporatically. > > >I've run e2fsck -c /dev/sda5 to no avail. I also upgraded the dump utility tha > >t came with the standard Red Hat 7.1 install to dump-04b21 to dump-04b22. Any > >ideas what can cause this and how I might fix it? > > No, but if anyone has any ideas, please post them to the list, I'll > try anything :) > > Thanks, > -- > > Seeya, > Paul > ---- > > God Bless America! > > ...we don't need to be perfect to be the best around, > and we never stop trying to be better. > Tom Clancy, The Bear and The Dragon
