Hi Josef, [..SNIP..] >> Yeah, very reasonable, if you don't mind, i would give a patch for this issue. > Go for it, you'll be faster than I will be, all I do is run xfstests and > try to reproduce things that will never reproduce for me. So Finally, i've figured everything out. Previous send is almostly safe is because we deal every item by transaction protection, and we will search next item from root again next time (see btrfs_search_slot_for_read()) And we will check root's @ctransid to make sure root did not change during send. (For readonly root, usually it should not except snapshot-aware defrag, ok we should fix it!!) Since we kicked off transaction from send, life will become a little complex,we should take care of everything can change readonly snapshot, from i can say now: 1. snapshot @send_root will cow everything 2. snapshot-aware defrag also work for readonly root. 3. balance, device resize, add,remove, scrub(repair mode) So there are two ideas in my mind: #Approach 1 convert to previous ways that means add transaction protection for send. and Filipe's optimizations for send search should be reverted, this way is simple and make codes less complex, but we will involve transaction protection. #Approach 2. Add a local flag to root structure to sync snapshot with send. Add a global flag to sync balance's etc options with send don't defray readonly snapshot for snapshot-aware defrag. Approach 2 will make it safe to avoid transaction from send, but it add complexity to codes.Personally, i do not like approach 2 very much because it make btrfs codes more *ugly* and make it *harder* to maintain. Anyway, I am ok to implement both ways, Tell me if you have any better ideas or which approach is your appreciated way to fix the issue^_^ Thanks, Wang > > Josef -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
