Bug 166415
Summary: | dump crashes when dumping filesystems between 1 and 2 TB in size | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 3 | Reporter: | Jefferson Ogata <jefferson.ogata> | ||||
Component: | dump | Assignee: | Adam Tkac <atkac> | ||||
Status: | CLOSED ERRATA | QA Contact: | Ben Levenson <benl> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | high | ||||||
Version: | 3.0 | CC: | dferbert, ovasik, stelian | ||||
Target Milestone: | --- | Keywords: | Reopened | ||||
Target Release: | --- | ||||||
Hardware: | i386 | ||||||
OS: | Linux | ||||||
Whiteboard: | RHEL3U7NAK | ||||||
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: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 189875 | ||||||
Attachments: |
|
Description
Jefferson Ogata
2005-08-20 19:49:05 UTC
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 |