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 How reproducible: 100% 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) Filesystem label=/foo 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, 102400000, 214990848 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! Segmentation fault DUMP: DUMP: DUMP: SIGSEGV: ABORTING! Actual results: Segfault. Expected results: Copy of filesystem. Additional info: 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 files.
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.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: http://people.redhat.com/jnovy/files/dump-0.4b37-2TB/ ? 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. http://rhn.redhat.com/errata/RHBA-2007-0421.html