On Wed, Sep 14, 2011 at 2:33 AM, Allison Henderson <achender@xxxxxxxxxxxxxxxxxx> wrote: > Hi All, > > I have been trying to find a way to synchronize punch hole with read and > write operations with out the use of i_mutex. The concern is that after > punch hole has released the pages inside the hole, another process may remap > the page to a block before punch has taken i_data_sem. I think putting > i_mutex around the punch hole operation would fix this, but since we are > trying to avoid further improper use of i_mutex, I am trying to avoid that > solution. > > I cannot use i_data_sem to protect the pages because it seems most of the > code has already established a locking order of pages first, then > i_data_sem. So moving i_data_sem up tends to cause a lot of dead locks. > I'm thinking that there probably needs to be a another mutex involved some > where, but I wasnt sure if some one is already working on the idea of > introducing a replacement for i_mutex. So I just wanted to know if there > are any plans already in motion for this, or if any one else could suggest > some ideas for the punch hole issue. Thx all! HI, Lukas sent out a patch ([PATCH] ext4: Make reads/writes atomic with i_rwlock semaphore) which collected some feedbacks suggesting using extent lock instead of a read-write semaphore. If there is extent lock implementation in ext4, then fallocate can use it, maybe dioread-nolock can use it as well, e.g. locking a range and unlocking the range until the extent is converted from unwritten to init. Yongqiang. > > Allison Henderson > > -- > 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 > -- Best Wishes Yongqiang Yang -- 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