On Wed 26-05-10 09:23:52, tytso@xxxxxxx wrote: > One more thing. Why do you need EXT4_STATE_EXT_TRUNC? > > The only place which tests it in any kind of real way is > ext4_ext_truncate_extend_restart(), and it is only called by one > function, ext4_ext_rm_leaf(), and *it* is only called in one place, > inside ext4_ext_remove_space(), and *it* surronds the call with > ext4_set_inode_state(inode, EXT4_STATE_EXT_TRUNC) and > ext4_clear_inode_state(inode, EXT4_STATE_EXT_TRUNC). > > And while a truncate is happening, no other block allocation can > happen, so the test in ext4_ext_map_blocks() doesn't seem to do much. This is false. As soon as we drop i_data_sem, allocation *can* happen from writeback path. Because truncate has already invalidated all the pages past new_size, it must be for some page before new_size but still it could modify an extent tree node we passed through when looking up our extent... > (It only clears STATE_EXT_TRUNC if it is set and if the flags > EXT4_GET_BLOCKS_CREATE is set. I'm not sure what the point of that > is, either.) I think the idea Dmitry tries to implement is: When allocation like I describe above happens while we droppped i_data_sem, restart the whole truncation. Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- 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
