On Wed, May 26, 2010 at 06:23:55PM +0400, Dmitry Monakhov wrote: > > Later if we face a needs to restart transaction which result in > i_data_sem indernal drop/acquire. > And when the sem was dropped new block may be allocated by a > flusher task (delay allocation writeback in the middle of the file) > > *Flusher* will discover than STATE_EXT_TRUNC is set and clear it > is allocation is really necessary(EXT4_GET_BLOCKS_CREATE is set) > By clearing STATE_EXT_TRUNC bit flusher let truncate task to know > what it have to restart it's job. OK, but why not have the truncate *always* restart its job after restarting the transaction? #1, it's relatively rare in most workloads that we need to restart the transaction at all in the first place, and #2, it's easier to test if we always restart the truncate, and #3, it's not like we'll be doing that much extra work if we restart the truncate and the file wasn't extended significantly... - 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