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
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: dump (Show other bugs)
3.0
i386 Linux
high Severity medium
: ---
: ---
Assigned To: Adam Tkac
Ben Levenson
RHEL3U7NAK
: 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:
Environment:
Last Closed: 2007-06-11 14:38:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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:
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.
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:
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.
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.

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.