Bug 5981 - dump gives short read error
dump gives short read error
Product: Red Hat Linux
Classification: Retired
Component: dump (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Preston Brown
Depends On:
  Show dependency treegraph
Reported: 1999-10-15 09:36 EDT by Per Starbäck
Modified: 2008-05-01 11:37 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-06-27 12:14:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Per Starbäck 1999-10-15 09:36:28 EDT
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%

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.)
Comment 1 lamont 1999-11-07 20:21:59 EST
I'm seeing exactly the same problem.  Similarly I've done fsck -f and
tried upgrading the RPMs.
Comment 2 lamont 1999-11-08 12:57:59 EST
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?
Comment 3 lamont 1999-11-10 19:55:59 EST
Upgrading to 2.2.12-20smp (via a complete install of RH6.1) does not
fix this problem.
Comment 4 Preston Brown 2000-06-27 12:14:42 EDT
was your problem fixed in 6.2?
Comment 5 Preston Brown 2000-07-13 15:01:11 EDT
closed due to lack of feedback; please re-open if it is not fixed in 6.2.

Note You need to log in before you can comment on or make changes to this bug.