On Mon, Oct 24, 2011 at 05:30:26PM -0500, Eric Sandeen wrote: > Ceph users reported that when using Ceph on ext4, the filesystem > would often become corrupted, containing inodes with incorrect > i_blocks counters. > > ... > > In other words, the sync/flush thread pops in and sets > i_delalloc_reserved_flag on the inode, which makes the xattr thread > think that it's in a delalloc path in ext4_new_meta_blocks(), > and add the block for a second time, after already having added > it once in the !i_delalloc_reserved_flag case in ext4_mb_new_blocks > > I think this can be as simple as taking i_data_sem before we > go down the new metablock path, so that we won't be testing > i_delalloc_reserved_flag in a race with xt4_get_blocks setting it. > > Signed-off-by: Eric Sandeen <sandeen@xxxxxxxxxx> Thanks, applied for now. > > This seems like slight abuse of i_data_sem though, since we are > not modifying i_data[] in the inode on the xattr path. But nothing > else protects readers of i_delalloc_reserved_flag in other > threads. Thoughts? Agreed, we really should be depending on the EXT4_GET_BLOCK_DELALLOC_RESERVE and EXT4_MB_DELALLOC_RESERVED flags. I can't remember what caused us to plumb in the i_state flag, but that's clearly a hack which is biting us hard. I'll take this patch for now since it fixes a real problem, but we should figure out a better way of fixing this, hopefully that results in the i_state flag going away. - Ted -- 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
