Bug 166415 - dump crashes when dumping filesystems between 1 and 2 TB in size
Summary: dump crashes when dumping filesystems between 1 and 2 TB in size
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: dump (Show other bugs)
(Show other bugs)
Version: 3.0
Hardware: i386 Linux
high
medium
Target Milestone: ---
Assignee: Adam Tkac
QA Contact: Ben Levenson
URL:
Whiteboard: RHEL3U7NAK
Keywords: Reopened
Depends On:
Blocks: 189875
TreeView+ depends on / blocked
 
Reported: 2005-08-20 19:49 UTC by Jefferson Ogata
Modified: 2018-10-19 20:21 UTC (History)
3 users (show)

Fixed In Version: RHBA-2007-0421
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-06-11 18:38:04 UTC
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 14:45 UTC, Adam Tkac
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2007:0421 normal SHIPPED_LIVE dump bug fix update 2007-06-07 20:16:24 UTC

Description Jefferson Ogata 2005-08-20 19:49:05 UTC
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 12:03:35 UTC
Does this also happen with the latest dump from http://dump.sourceforge.net ?



Comment 2 Jefferson Ogata 2005-08-22 07:18:34 UTC
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 07:22:09 UTC
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 08:15:54 UTC
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 20:30:09 UTC
Seems to have a bad MD5 sum. Can you check the packages?

Comment 6 Jefferson Ogata 2005-08-22 21:00:48 UTC
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 18:56:04 UTC
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 14:45:15 UTC
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 16:42:12 UTC
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 17:02:17 UTC
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 19:43:03 UTC
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 09:34:39 UTC
well, look ahead 3.9 update of rhel-3

Comment 25 Red Hat Bugzilla 2007-06-11 18:38:04 UTC
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.