Red Hat Bugzilla – Bug 166415
dump crashes when dumping filesystems between 1 and 2 TB in size
Last modified: 2018-10-19 16:21:27 EDT
Description of problem:
When I attempt to dump a filesystem between 1 and 2 TB in size, a segfault
occurs. This happens even if the source filesystem is pristine and contains
nothing more than an empty lost+found directory.
Version-Release number of selected component (if applicable):
0.4b37-1E and others
Steps to Reproduce:
1. Create a filesystem between 1 and 2 TB in size:
/root/x# fdisk -l /dev/sdb
Disk /dev/sdb: 1799.8 GB, 1799859732480 bytes
255 heads, 63 sectors/track, 218820 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdb1 1 218820 1757671618+ 83 Linux
/root# mkfs.ext3 -L /foo /dev/sdb1
mke2fs 1.32 (09-Nov-2002)
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
219709440 inodes, 439417904 blocks
21970895 blocks (5.00%) reserved for the super user
First data block=0
13410 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 30 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
2. Try to dump the filesystem (you must wait for mapping passes to finish and
dumping to begin):
/root# dump 0af /tmp/foo /dev/sdb1
DUMP: Date of this level 0 dump: Sat Aug 20 19:09:11 2005
DUMP: Dumping /dev/sdb1 (an unlisted file system) to /tmp/foo
DUMP: Label: /foo
DUMP: Writing 10 Kilobyte records
DUMP: mapping (Pass I) [regular files]
DUMP: mapping (Pass II) [directories]
DUMP: estimated 53667 blocks.
DUMP: Volume 1 started with block 1 at: Sat Aug 20 19:28:55 2005
DUMP: SIGSEGV: ABORTING!
DUMP: SIGSEGV: ABORTING!
DUMP: DUMP: DUMP: SIGSEGV: ABORTING!
Copy of filesystem.
Red Hat appears to indicate that ext3 filesystems of up to 2TB are supported on
x86 RHEL 3 (though it's hard to find specific wording on this). But if you can't
dump a filesystem, you can't make an accurate copy of a filesystem with sparse
Does this also happen with the latest dump from http://dump.sourceforge.net ?
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.
To be clear, dump 0.4b40-1 did not crash on any partition size up to 218820
cylinders (~1.7 TB), which is the maximum I tested. The cutoff point I reported
is for the stock version 0.4b37-1E.
Could you please test this fixed RHEL3 version of the dump-0.4b37:
Update to dump-0.4b37-3.EL3.i386.rpm would be sufficient to test it.
Seems to have a bad MD5 sum. Can you check the packages?
Never mind--rebuilt it from your SRPM.
It doesn't segfault on a pristine filesystem so that's better. I will further
test dump/restore on a real volume. This will take some time...
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.
Created attachment 140563 [details]
I've added source package for testing
please, could you test with this package?? thanks
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.
Quality Engineering Management has reviewed and declined this request. You may
appeal this decision by reopening this request.
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!
well, look ahead 3.9 update of rhel-3
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.