http://bugzilla.kernel.org/show_bug.cgi?id=14354 --- Comment #154 from Aneesh Kumar K.V <aneesh.kumar@xxxxxxxxxxxxxxxxxx> 2009-10-30 10:42:38 --- To further update on 487caeef9fc08c0565e082c40a8aaf58dad92bbb, If we happen to create a prealloc space mapping the same offset that we are truncating them we can end up having multiple claimed blocks. ext4_mb_return_to_preallocation which is done during truncate doesn't put the blocks back into prealloc space because it depends on us discarding the prealloc space at the beginning of the truncate. Now whether we can end up having block allocation that can get a prealloc space mapping the same offset that we are truncating is something i haven't yet figured out. We do invalidate all pages before we start a truncate. That would imply flusher threads will not find any of those dirty pages. Also for multiple claimed blocks to happen we should get the same block number that we are freeing via truncate. AFAIU that cannot happen because bits mapping those blocks are marked used in buddy cache. So we cannot preallocate them. But i guess discarding prealloc space after reacquiring i_data_sem seemed to be a safe bet to me. But still doesn't fully explain why we end up having multiple claimed blocks. May be i am missing some code paths in the above analysis. -aneesh -- 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
