Bug 232677 - ext2/3 filesystem corruption with writable loopback devices on s390
ext2/3 filesystem corruption with writable loopback devices on s390
Status: CLOSED DUPLICATE of bug 236605
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.0
s390x Linux
high Severity high
: ---
: ---
Assigned To: Jan Glauber
Martin Jenner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-16 12:11 EDT by Bryn M. Reeves
Modified: 2008-01-08 08:04 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-30 09:58:05 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)
currupt file system image (1.51 KB, application/octet-stream)
2007-04-20 22:53 EDT, Bryn M. Reeves
no flags Details
reproducer script (476 bytes, text/plain)
2007-04-21 14:18 EDT, Bryn M. Reeves
no flags Details

  None (edit)
Description Bryn M. Reeves 2007-03-16 12:11:05 EDT
Description of problem:
Creating an ext3/3 filesystem on a writable loopback device on s390 leads to
corruption of the resize inode.

Version-Release number of selected component (if applicable):
kernel-2.6.18-8.EL

How reproducible:
100%

Steps to Reproduce:
1. dd if=/dev/zero of=/tmp/img0
2. losetup /dev/loop0 /tmp/img0 
2. mke2fs -j /dev/loop0
3. mount /dev/loop0 /mnt
4. ls -R /mnt
5. umount /mnt
6. e2fsck -fn /dev/loop0

Actual results:
# e2fsck -fn /dev/loop0
e2fsck 1.39 (29-May-2006)
Resize inode not valid.  Recreate? no

Pass 1: Checking inodes, blocks, and sizes
Inode 7, i_blocks is 254, should be 4.  Fix? no

Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

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

/dev/loop0: 11/4096 files (9.1% non-contiguous), 1691/16384 blocks


Expected results:
# e2fsck -fn /dev/loop0
e2fsck 1.39 (29-May-2006)
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
/dev/loop0: 11/4096 files (9.1% non-contiguous), 1691/16384 blocks


Additional info:
The resize inode is always affected. On other filesystems there's also sometimes
problems in the dtime field of deleted inodes, e.g:


Resize inode not valid.  Recreate? no

Pass 1: Checking inodes, blocks, and sizes
Inode 7, i_blocks is 254, should be 252.  Fix? no

Deleted inode 17 has zero dtime.  Fix? no

Deleted inode 25 has zero dtime.  Fix? no


I wasn't able to reproduce this with msdos/vfat. Haven't tested with other fs types.
Comment 2 Eric Sandeen 2007-04-20 16:41:16 EDT
Hmm maybe you can bzip2 the /tmp/img0 image & attach it?

Does an image created on s390 check ok on x86, or vice versa?

The whole sequence works fine for me on x86

It's odd that you see an inode 25 on a fresh fs with no files....
Comment 3 Bryn M. Reeves 2007-04-20 22:42:40 EDT
It's s390 specific - I hit it while reproducing bug 232663 (big endian specific)
and found I couldn't reproduce it on ppc.

It sounds a lot like 236605 - fixed in 2.6.18-8.1.3.el5. I've run through about
five mkfs/mount/fsck cycles now without seeing it.

Comment 4 Bryn M. Reeves 2007-04-20 22:53:13 EDT
Created attachment 153232 [details]
currupt file system image

Corrupt file system image (2M uncompressed)
Comment 5 Eric Sandeen 2007-04-20 23:23:05 EDT
Thanks Bryn.  What exactly was done to create this image?
Comment 6 Bryn M. Reeves 2007-04-21 14:11:00 EDT
As described in comment #1: a dd from /dev/zero to set up the image (bs=1M
count=2), then losetup, then mke2fs -j on the loop device.

It should be quite easy to reproduce on s390 (at least with a kernel prior to
2.6.18-8.1.3.el5). I've still not seen it on the later kernel, but I'll keep
testing for now.

I'm fairly certain this is just another instance of the page_mkclean problem
from bug 236605. When I first saw this it seemed to happen every time, but
running a script 1000 times just now gave me 236 failures on 2.6.18-8.el5. The
same script on 2.6.18-8.1.3.el5 didn't see any corruption in 1000 runs.
Comment 7 Bryn M. Reeves 2007-04-21 14:18:43 EDT
Created attachment 153245 [details]
reproducer script
Comment 9 Eric Sandeen 2007-04-21 17:46:20 EDT
Thanks Bryn.  If you're pretty sure this is already resolved by 236605, I'm
happy to wait 'til I hear otherwise... :)
Comment 10 RHEL Product and Program Management 2007-04-25 16:38:44 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 11 Bryn M. Reeves 2007-05-30 09:58:05 EDT
Eventually got back to testing this with 2.6.18-8.el5 plus the patch for bug
236605 - same result. I see errors around 25% of the time without it which
disappear when it's applied - I think it's safe to close this as a dup.


*** This bug has been marked as a duplicate of 236605 ***

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