Bug 166415 - dump crashes when dumping filesystems between 1 and 2 TB in size
dump crashes when dumping filesystems between 1 and 2 TB in size
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: dump (Show other bugs)
i386 Linux
high Severity medium
: ---
: ---
Assigned To: Adam Tkac
Ben Levenson
: Reopened
Depends On:
Blocks: 189875
  Show dependency treegraph
Reported: 2005-08-20 15:49 EDT by Jefferson Ogata
Modified: 2013-04-30 19:33 EDT (History)
3 users (show)

See Also:
Fixed In Version: RHBA-2007-0421
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-06-11 14:38:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
I've added source package for testing (236.75 KB, application/octet-stream)
2006-11-07 09:45 EST, Adam Tkac
no flags Details

  None (edit)
Description Jefferson Ogata 2005-08-20 15:49:05 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

How reproducible:

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
Segmentation fault

Actual results:

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
Comment 1 Stelian Pop 2005-08-21 08:03:35 EDT
Does this also happen with the latest dump from http://dump.sourceforge.net ?

Comment 2 Jefferson Ogata 2005-08-22 03:18:34 EDT
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.

Comment 3 Jefferson Ogata 2005-08-22 03:22:09 EDT
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.
Comment 4 Jindrich Novy 2005-08-22 04:15:54 EDT
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.
Comment 5 Jefferson Ogata 2005-08-22 16:30:09 EDT
Seems to have a bad MD5 sum. Can you check the packages?
Comment 6 Jefferson Ogata 2005-08-22 17:00:48 EDT
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...
Comment 12 Andrew Ferbert 2006-10-25 14:56:04 EDT
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.
Comment 13 Adam Tkac 2006-11-07 09:45:15 EST
Created attachment 140563 [details]
I've added source package for testing

please, could you test with this package?? thanks
Comment 14 Andrew Ferbert 2006-11-07 11:42:12 EST
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.
Comment 15 RHEL Product and Program Management 2006-11-07 12:02:17 EST
Quality Engineering Management has reviewed and declined this request.  You may
appeal this decision by reopening this request. 
Comment 16 Andrew Ferbert 2006-11-07 14:43:03 EST
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!
Comment 18 Adam Tkac 2006-11-15 04:34:39 EST
well, look ahead 3.9 update of rhel-3
Comment 25 Red Hat Bugzilla 2007-06-11 14:38:04 EDT
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.


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