RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1097061 - e2image can be run on a mounted filesystem
Summary: e2image can be run on a mounted filesystem
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: e2fsprogs
Version: 6.4
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Eric Sandeen
QA Contact: dhe
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-05-13 05:55 UTC by Lachlan McIlroy
Modified: 2018-12-06 16:29 UTC (History)
3 users (show)

Fixed In Version: e2fsprogs-1.41.12-20.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-10-14 07:54:19 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:1566 0 normal SHIPPED_LIVE e2fsprogs bug fix and enhancement update 2014-10-14 01:27:40 UTC

Description Lachlan McIlroy 2014-05-13 05:55:42 UTC 
Description of problem:

e2image should not be allowed to run on a mounted filesystem.  Allowing it to run on a mounted filesystem while changes are being made to the filesystem results in an inconsistent e2image that may exhibit corruption that is not present on the source filesystem.

Additionally since the journal inode is near the start of the disk the journal will be copied early in the e2image run.  While e2image is reading the metadata from the rest of the filesystem further changes are being made such that the filesystem is ahead of the contents of the journal.  When e2fsck reads this e2image it sees that the 'needs_recovery' flag is set in the superblock (because the filesystem is mounted) so it requires a journal replay.  But when e2fsck replays the journal it regresses the filesystem state because the journal is missing changes that were made after the journal was captured and this can cause a lot of corruption.

Version-Release number of selected component (if applicable):
e2fsprogs-1.41.12-14.el6.x86_64

How reproducible:
Every time if you are just running e2image on a mounted filesystem.  To demonstrate the corruption caused by replaying the journal requires a large filesystem with an active load.
Comment 1 Lachlan McIlroy 2014-05-13 05:58:57 UTC 
Here's an example from case 01089633:

After restoring the image I ran 'e2fsck -fn /dev/loop0' and there were only a couple of errors:

e2fsck 1.41.14 (22-Dec-2010)
Warning: skipping journal recovery because doing a read-only filesystem check.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong (504542647, counted=497830816).
Fix? no

Free inodes count wrong (128163829, counted=128152494).
Fix? no


/dev/loop0: ********** WARNING: Filesystem still has errors **********

/dev/loop0: 11/128163840 files (1863.6% non-contiguous), 8094804/512637451 blocks



Running e2fsck -fy /dev/loop0 reported a whole lot of errors starting with:

e2fsck 1.41.14 (22-Dec-2010)
/dev/loop0: recovering journal
e2fsck: Group descriptors look bad... trying backup blocks...
e2fsck: Bad magic number in super-block when using the backup blocks
e2fsck: going back to original superblock
Note: if several inode or block bitmap blocks or part
of the inode table require relocation, you may wish to try
running e2fsck with the '-b 32768' option first.  The problem
may lie only with the primary block group descriptors, and
the backup block group descriptors may be OK.

Block bitmap for group 13824 is not in group.  (block 2553887680)
Relocate? yes

One or more block group descriptor checksums are invalid.  Fix? yes
...

It would seem that recovering the journal has done more damage to the filesystem than was already present.
Comment 3 Eric Sandeen 2014-05-13 12:42:54 UTC 
Agreed.  I asked Carlos to fix this and he sent a patch upstream:

[PATCH] e2image: Print a warning if running over a mounted filesystem

Several users use to run e2image over a mounted RW filesystem, providing
inconsistent, useless e2images for debugging purposes.
This patch adds a warning in such cases, notifying the user and also adds a
force option making e2image able to run in such cases.
Also print a warning when not using qcow or raw formats but allows image
creation to proceed, since, such images might be used for metadata backup
purposes.

Signed-off-by: Carlos Maiolino <cmaiolino>
---

I think it's committed; if not I'll hassle Ted - may as well fix this now.
Comment 4 Eric Sandeen 2014-05-13 15:22:49 UTC 
http://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/commit/?h=next&id=6c327e9ca47fa4e51efe3a6601ad661b8c1a3964
Comment 5 Lachlan McIlroy 2014-05-14 01:43:37 UTC 
Thanks Eric.
Comment 6 Eric Sandeen 2014-05-14 01:46:24 UTC 
Here to serve, Lachlan.  ;)
Comment 11 Eric Sandeen 2014-09-09 16:14:12 UTC 
Moving back to ASSIGNED to try to get blocker status so I can fix the defect coverity found after I filed the errata...
Comment 12 Eric Sandeen 2014-09-09 16:16:55 UTC 
Never mind, not going to fix it this late in release.

Eguan, can you set it back to verified?
Comment 13 Eryu Guan 2014-09-10 03:48:31 UTC 
I'll file a new bug to track the coverity issue for 6.7
Comment 14 Eryu Guan 2014-09-10 08:32:22 UTC 
Bug 1139936 for the coverity defect issue.
Comment 15 errata-xmlrpc 2014-10-14 07:54:19 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-1566.html
Note You need to log in before you can comment on or make changes to this bug.