Re: [DOC] BTRFS Volume operations, Device Lists and Locks all in one page

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

[-- Attachment #1.1: Type: text/plain, Size: 4379 bytes --]



On 2018年07月13日 08:20, Qu Wenruo wrote:
> 
> 
> [snip]
>>> In this case, it depends on when and how we mark the device resilvering.
>>> If we record the generation of write error happens, then just initial a
>>> scrub for generation greater than that generation.
>>
>>  If we record all the degraded transactions then yes. Not just the last
>>  failed transaction.
> 
> The last successful generation won't be upgraded until the scrub success.
> 
>>
>>> In the list, some guys mentioned that for LVM/mdraid they will record
>>> the generation when some device(s) get write error or missing, and do
>>> self cure.
>>>
>>>>
>>>>   I have been scratching on fix for this [3] for some time now. Thanks
>>>>   for the participation. In my understanding we are missing across-tree
>>>>   parent transid verification at the lowest possible granular OR
>>>
>>> Maybe the newly added first_key and level check could help detect such
>>> mismatch?
>>>
>>>>   other approach is to modify Liubo approach to provide a list of
>>>>   degraded chunks but without a journal disk.
>>>
>>> Currently, DEV_ITEM::generation is seldom used. (only for seed sprout
>>> case)
>>> Maybe we could reuse that member to record the last successful written
>>> transaction to that device and do above purposed LVM/mdraid style self
>>> cure?
>>
>>  Record of just the last successful transaction won't help. OR its an
>>  overkill to fix a write hole.
>>
>>  Transactions: 10 11 [12] [13] [14] <---- write hole ----> [19] [20]
>>  In the above example
>>   disk disappeared at transaction 11 and when it reappeared at
>>   the transaction 19, there were new writes as well as the resilver
>>   writes,
> 
> Then the last good generation will be 11 and we will commit current
> transaction as soon as we find a device disappear, and won't upgrade the
> last good generation until the scrub finishes.
> 
>> so we were able to write 12 13 14 and 19 20 and then
>>   the disk disappears again leaving a write hole.
> 
> Only if in above transactions, the auto scrub finishes, the device will
> has generation updated, or it will stay generation 11.
> 
>> Now next time when
>>   disk reappears the last transaction indicates 20 on both-disks
>>   but leaving a write hole in one of disk.
> 
> That will only happens if auto-scrub finishes in transaction 20, or its
> last successful generation will stay 11.
> 
>> But if you are planning to
>>   record and start at transaction [14] then its an overkill because
>>   transaction [19 and [20] are already in the disk.
> 
> Yes, I'm doing it overkilled.
> But it's already much better than scrub all block groups (my original plan).

Well, my idea has a major problem, that's we don't have generation for
block group item, that's to say either we use free space cache
generation or add new BLOCK_GROUP_ITEM member for generation detection.

Thanks,
Qu

> 
> Thanks,
> Qu
> 
>>
>> Thanks, Anand
>>
>>
>>> Thanks,
>>> Qu
>>>
>>>>     [3] https://patchwork.kernel.org/patch/10403311/
>>>>
>>>>   Further, as we do a self adapting chunk allocation in RAID1, it needs
>>>>   balance-convert to fix. IMO at some point we have to provide degraded
>>>>   raid1 chunk allocation and also modify the scrub to be chunk granular.
>>>>
>>>> Thanks, Anand
>>>>
>>>>> Any idea on this?
>>>>>
>>>>> Thanks,
>>>>> Qu
>>>>>
>>>>>> Unlock: btrfs_fs_info::chunk_mutex
>>>>>> Unlock: btrfs_fs_devices::device_list_mutex
>>>>>>
>>>>>> -----------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>> Thanks, Anand
>>>>>> -- 
>>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>>> linux-btrfs" in
>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>
>>>> -- 
>>>> To unsubscribe from this list: send the line "unsubscribe
>>>> linux-btrfs" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>> -- 
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]