On 12/7/12 6:26 AM, Forrest Liu wrote: > 2012/12/7 Ashish Sangwan <ashishsangwan2@xxxxxxxxx>: >> On Thu, Dec 6, 2012 at 9:18 PM, Eric Sandeen <sandeen@xxxxxxxxxx> wrote: >>> On 12/6/12 9:45 AM, Eric Sandeen wrote: >>>> On 12/4/12 6:11 AM, Forrest Liu wrote: >>>>> Extent indexes didn't update correctly in ext4_ext_rm_idx, when depth >>>>> of extent tree is greater than 1. >>>> >>>> This is interesting; we had 2 reports of similar corruption on the >>>> list, I wonder if the application in question was doing hole punching. >>>> I didn't expect that they were, so TBH I was pretty much ignoring >>>> the hole-punch cases for parent index updates. Hm. I'll have >>>> to look into that. >>>> Could you turn your testcase into an xfstest regression test? > > Hi Eric, > I will check how to do that. >>> >>> Also, please note that I sent an e2fsck patch to try to fix this >>> problem after the fact; it'd be great if in your testing, you could >>> also confirm that e2fsck w/ my patch fixes it correctly. >>> >> I checked you patch. >> This was the extent tree situation after removing 1st extent index: >> debugfs: ex abc >> Level Entries Logical Physical Length Flags >> 0/ 2 1/ 1 0 - 8399 32857 8400 >> 1/ 2 1/ 4 2048 - 4081 4138 2034 >> 2/ 2 1/339 2048 - 2053 69632 - 69637 6 >> 2/ 2 2/339 2054 - 2059 69656 - 69661 6 >> >> E2fsck's output with your patch=> >> Linux#> /dtv/usb/sdb1/e2fsck /dev/sda1 -f >> e2fsck 1.42.6.1 (06-DEC-2012) >> Pass 1: Checking inodes, blocks, and sizes >> Interior extent node level 0 of inode 31: >> Logical start 0 does not match logical start 2048 at next level. Fix<y>? yes >> Inode 31, i_blocks is 50856, should be 16280. Fix<y>? yes > > I got similar result, pb->num_blocks is incorrect if > ext2fs_extent_fix_parents called. Maybe I should ask what it looks like without my patch? I didn't think my patch would change anything at all about block count or use. -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
