Re: [PATCH] Btrfs: convert to add transaction protection for btrfs send

[Josef Bacik <jbacik@fb.com>]

On 02/05/2014 12:23 PM, Wang Shilong wrote:
> Hi Josef,
>
>> On 02/05/2014 03:59 AM, Wang Shilong wrote:
>>> Hi Josef,
>>>
>>> [..SNIP..]
>>>> On 01/31/2014 11:37 AM, Wang Shilong wrote:
>>>>> Hello Josef,
>>>>>
>>>> 2) Remove the per-root rwsem for the commit root and just make one big
>>>> rwsem that covers all commit root switching. This way everybody who
>>>> wants to search with the commit root can just use this semaphore and all
>>>> be safe. It will mean that the inode cache stuff may block longer than
>>>> normal but I don't think that's too big of a deal.
>>>>
>>> I am ok with this fix,  I wanted to talk something about protecting searching commit file root, this is really a
>>> problem especially for full send.
>>>
>>> I have some ideas about this issue:
>>>
>>> #1.don't use commit file root to search.
>>> This will become a nightmare when we are doing full send which will iterate the whole file tree,
>>> at the same time, we snapshot send root, snapshots will be blocked until send finished.
>>>
>>> #2. don't allow snapshot if we are sending root.
>>> This may be a little confusing, snapshots are readonly, but users can not snapshot it.
>> I think this is the best bet. The fact is we don't want to hold this
>> commit_root_sem for the entire duration of the send, it would block
>> people trying to commit the transaction. We could check for contention
>> and drop the sem and re-search down to where we were but I think that
>> would be prone to errors. If we just check to see if the snapshot is
>> being sent and just return -EBUSY when we try to create a snapshot I
>> think that's perfectly reasonable.
>>> #3. after one iteration, we do check send_root's generation, and make sure it doesn't
>>> change, if it changed, then we restart send again.
>>>
>>> I don't know which approach is better,and also snapshot-aware defragment will change
>>> read-only snapshot?
>>>
>>> Did you have any better ideas about this issue? Share it with me here.^_^
>>>
>> Snapshot-aware defrag will definitely screw us here. I think we need to
>> do the same thing above as we do here, which is to simply skip the
>> snapshot aware defrag if we are currently using that root for send. This
>> sound reasonable to you? Thanks,
> 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.

Josef