I've built dump-0.4b40-1 from SRPM downloaded from dump.sourceforge.net, and it
does not exhibit this problem. In fact, the changelog for 0.4b38 notes:
"5. Fix dump crash when backuping a huge (2TB) filesystem,
due to a bogus calculation on the inode map size.
Thanks to Kevin B. Haines <K.B.Haines@rl.ac.uk> for
submitting the bug and testing the fix."
So this may be the problem.
In addition, I retested using various partition sizes to find the cutoff point
where it stops working. I find that with a partition of 138847 cylinders
(8225280 bytes per cylinder), dump on a pristine filesystem is successful, but
dump crashes if the underlying partition is 138848 cylinders or larger.

I realize this is old, but we're starting to run into these issues ourselves.
Is there a location that the 4b37-3 rpm/srpm is still available for testing? I
can quickly provide information as to the resolution if i can get the files.

I also submitted a ticket to Redhat support and received both i386 and x86_64
binary rpms for 0.4b37-3.
Both seemed to work fine-- I was able to dump and 'restore -i' (although i
didn't actually attempt file retrieval) on a filesystem:
> df /dev/sdb1
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sdb1 2018527152 67417644 1848574248 4% /data2
Service request number 1069352 is my open ticket, if that helps you too.

Can i get clarification on why this is WONTFIX?
We are currently using this 0.4b47-3 binary in our production environment for
the 2TB filesystems, but if there is a known issue i would like to find another
backup method. Thanks!

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.
http://rhn.redhat.com/errata/RHBA-2007-0421.html

Note

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