Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 5981 - dump gives short read error
Summary: dump gives short read error
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: dump
Version: 6.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Preston Brown
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 1999-10-15 13:36 UTC by Per Starbäck
Modified: 2008-05-01 15:37 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2000-06-27 16:14:44 UTC

Attachments (Terms of Use)

Description Per Starbäck 1999-10-15 13:36:28 UTC
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-08 01:21:59 UTC
I'm seeing exactly the same problem.  Similarly I've done fsck -f and
tried upgrading the RPMs.

Comment 2 lamont 1999-11-08 17:57:59 UTC
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-11 00:55:59 UTC
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 16:14:42 UTC
was your problem fixed in 6.2?

Comment 5 Preston Brown 2000-07-13 19:01:11 UTC
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.