Hide Forgot
I have had numerous problems with dumping a particular partition, although fsck doesn't complain about it. * Yes, I have used the -f(orce) switch to e2fsck. * I have tried to use dump when the file system has been fairly inactive, but it *has* been mounted. * This partition is rather large, which maybe has to do with the problem? /dev/sdb1 17125727 15655223 578499 96% /modus/export3 The errors are during phase 4 of the dump and look typically like this: DUMP: 57.80% done, finished in 6:56 DUMP: bread: lseek fails DUMP: DUMP: DUMP: bread: lseek fails DUMP: short read error from /dev/sdb1: [block -1026890544]: count=1024, got=0 DUMP: bread: lseek2 fails! DUMP: short read error from /dev/sdb1: [sector -1026890544]: count=512, got=0 DUMP: bread: lseek2 fails! DUMP: short read error from /dev/sdb1: [sector -1026890543]: count=512, got=0 [...] DUMP: More than 32 block read errors from 134570064 DUMP: This is an unrecoverable error. "got" is always 0. (This looks similar to bug 1015, but there it is said to be a SPARC bug, and to be fixed in dump-0.3-17.) I have tried updating to see if the problem would go away, so now I use dump-0.4b4-11 and e2fsprogs-1.15-4 in a RH6.0 system.)
I'm seeing exactly the same problem. Similarly I've done fsck -f and tried upgrading the RPMs.
Switching from 2.2.5-15smp to 2.2.5-15 (non-SMP) seems to have 'fixed' this problem. Is this a problem with the kernel locking so that perhaps an updated SMP kernel would not exhibit this problem, or is this a problem with dump?
Upgrading to 2.2.12-20smp (via a complete install of RH6.1) does not fix this problem.
was your problem fixed in 6.2?
closed due to lack of feedback; please re-open if it is not fixed in 6.2.