On Sun, Feb 9, 2014 at 2:39 AM, Shilong Wang <wangshilong1...@gmail.com> wrote: > 2014-02-08 23:46 GMT+08:00 Wang Shilong <wangshilong1...@gmail.com>: >> From: Wang Shilong <wangsl.f...@cn.fujitsu.com> >> >> This reverts commit 41ce9970a8a6a362ae8df145f7a03d789e9ef9d2. >> Previously i was thinking we can use readonly root's commit root >> safely while it is not true, readonly root may be cowed with the >> following cases. >> >> 1.snapshot send root will cow source root. >> 2.balance,device operations will also cow readonly send root >> to relocate. >> >> So i have two ideas to make us safe to use commit root. >> >> -->approach 1: >> make it protected by transaction and end transaction properly and we research >> next item from root node(see btrfs_search_slot_for_read()). >> >> -->approach 2: >> add another counter to local root structure to sync snapshot with send. >> and add a global counter to sync send with exclusive device operations. >> >> So with approach 2, send can use commit root safely, because we make sure >> send root can not be cowed during send. Unfortunately, it make codes *ugly* >> and more complex to maintain. >> >> To make snapshot and send exclusively, device operations and send operation >> exclusively with each other is a little confusing for common users. >> >> So why not drop into previous way. >> >> Cc: Josef Bacik <jba...@fb.com> >> Signed-off-by: Wang Shilong <wangsl.f...@cn.fujitsu.com> >> --- >> Josef, if we reach agreement to adopt this approach, please revert >> Filipe's patch(Btrfs: make some tree searches in send.c more efficient) >> from btrfs-next. > > Oops, this patch guarantee searching commit roots are all protected by > transaction, Filipe's > patch is ok, we need update Josef's previous patch.
Hi Shilong, I am confused. Can you explain why that optimization patch is a problem, either with or without your patch or any other patch currently flying around? Either before or after the optimization, we search through the commit root and after a key search we process a key while holding the leaf's extent buffer. Both approaches call btrfs_next_leaf too (either directly or via btrfs_search_slot_for_read). Thanks > > Wang > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Filipe David Manana, "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men." -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
