Dmitry Monakhov wrote: > If we have failed some where inside ext4_get_blocks() internals we may > have allocated some new blocks, which was not yet claimed to quota. > We have to free such blocks, but without touching quota. Quota will > be updated later on exit from ext4_get_blocks(). > There are two possible ways to understand what we have to skip quota update: > 1) Caller pass corresponding flag to ext4_free_blocks() > 2) check that free_blocks() was indirectly called by get_blocks() > (i.e EXT4_I(inode)->i_delalloc_reserved_flag is set) > Second is simpler, but may result in unpredictable consequences later. > So i've chosen the first one, because caller must know which blocks it > is freeing. > > Eric, please take your attention to metadata blocks handling when > you will work on new versing of "ext4: don't use quota reservation for > speculative metadata blocks" patch. > > The bug happens on heavily loaded node, or with 227'th xfstestcase and hm which test? 227 is xfs-only... -Eric > result in incorrect i_blocks (less than expected). So truncation for > that file result in i_blocks overflow. > Seems this was the last bug which was easily triggered by 227'th testcase. > > -- 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
