Bug 43354
Summary: | Corruption on a small loopback ext4 file system with Linux 3.4 | ||
---|---|---|---|
Product: | File System | Reporter: | Alec Moskvin (alecm) |
Component: | ext4 | Assignee: | Jan Kara (jack) |
Status: | RESOLVED UNREPRODUCIBLE | ||
Severity: | high | CC: | jack, sandeen |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 3.4.1 | Subsystem: | |
Regression: | Yes | Bisected commit-id: | |
Attachments: | tree.ext4.xz - resulting fs image |
Description
Alec Moskvin
2012-06-08 03:59:03 UTC
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. |