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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
--
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




[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux