With Linux 3.4, I am getting major corruption on a loopback ext4 filesystem: parts of files are randomly inserted into other files. Below are steps to reproduce - I've been able to reproduce this on two different systems. Both have ext4 root, using a plain kernel.org 3.4.1 kernel. The problem does not reproduce when switching back to Linux 3.3.6. If you need any additional info, I'll be happy to provide it. # uname -r 3.4.1 # dd if=/dev/zero of=tree.ext4 bs=1M count=512 512+0 records in 512+0 records out 536870912 bytes (537 MB) copied, 0.589387 s, 911 MB/s # mkfs.ext4 -T small -N 200000 tree.ext4 mke2fs 1.42.3 (14-May-2012) tree.ext4 is not a block special device. Proceed anyway? (y,n) y Discarding device blocks: done Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) Stride=0 blocks, Stripe width=0 blocks 200192 inodes, 524288 blocks 26214 blocks (5.00%) reserved for the super user First data block=1 Maximum filesystem blocks=67633152 64 block groups 8192 blocks per group, 8192 fragments per group 3128 inodes per group Superblock backups stored on blocks: 8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409 Allocating group tables: done Writing inode tables: done Creating journal (16384 blocks): done Writing superblocks and filesystem accounting information: done # mkdir tree # mount -o loop tree.ext4 tree # tar xaf portage-20120607.tar.xz -C tree # find tree -type f -exec sha1sum {} \; > checksums # umount tree # sync # echo 3 > /proc/sys/vm/drop_caches # important! everything will seem fine otherwise # fsck.ext4 -f tree.ext4 e2fsck 1.42.3 (14-May-2012) 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 tree.ext4: 183722/200192 files (0.0% non-contiguous), 402575/524288 blocks # mount -o loop tree.ext4 tree # sha1sum --check --quiet checksums tree/portage/net-firewall/conntrack-tools/ChangeLog: FAILED tree/portage/net-firewall/conntrack-tools/files/conntrackd.initd-r1: FAILED tree/portage/net-firewall/nufw/ChangeLog: FAILED ...
Created attachment 73536 [details] tree.ext4.xz - resulting fs image
Does it go any better w/ a 4k fs block size? (-b 4096?)
Yes, it seems to work fine with the 4k block size. mkfs.ext4 -T small -N 200000 -b 4096 tree.ext4 (Of course, I had to also double the image size because otherwise the data won't fit, but the size does not have an effect - the above is reproducible with a 1G image as well.)
Hm, wait - drop caches _after_ unmount is required? Ok that's even weirder (and scarier - especially since it's after a sync) And - on further testing, ext2 & ext3 fail too. Yikes. It also seems to happen only on loopback; a real device is fine. And, loopback fails whether it's hosted on ext4 or xfs. So something generic broke here...
Hmm, I'm not able to reproduce with 3.5-rc1. Can you?
I can't reproduce with 3.5 either.
Ok, thanks for verification. I'll close this bug then.