http://bugzilla.kernel.org/show_bug.cgi?id=15231 --- Comment #8 from Theodore Tso <tytso@xxxxxxx> 2010-02-09 18:27:22 --- Well, the BUG_ON getting tripped as reported in comment #1 in this bug is: BUG_ON(mdblocks < EXT4_I(inode)->i_reserved_meta_blocks); ... and the commit 39bc680a does mess with how i_reserved_meta_blocks is calculated. @@ -1836,10 +1834,11 @@ repeat: } return -ENOSPC; } + spin_lock(&EXT4_I(inode)->i_block_reservation_lock); EXT4_I(inode)->i_reserved_data_blocks += nrblocks; - EXT4_I(inode)->i_reserved_meta_blocks = mdblocks; - + EXT4_I(inode)->i_reserved_meta_blocks += md_needed; spin_unlock(&EXT4_I(inode)->i_block_reservation_lock); + return 0; /* success */ I'm going to need to go back and see whether I screwed up earlier and blamed the wrong commit earlier, or whether that commit was implicated in some other regression. However, given the claimed regression between 2.6.32.2 and 2.6.32.7, and given that commit 39bc680a was applied between 2.6.32.2 and 2.6.32.3, at the very least we should try backing out 39bc680a and seeing whether that makes Franco's problem go away. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. -- 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
