Re: [PATCH v2] btrfs: use preallocated pages for super block write

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

On 2022/6/10 15:39, Nikolay Borisov wrote:
>
>
> On 10.06.22 г. 10:33 ч., Qu Wenruo wrote:
>>
>>
>> On 2022/6/10 15:23, Nikolay Borisov wrote:
>>>
>>>
>>> On 10.06.22 г. 3:07 ч., Qu Wenruo wrote:
>>>>
>>>>
>>>> On 2022/6/10 00:46, David Sterba wrote:
>>>>> Currently the super block page is from the mapping of the block
>>>>> device,
>>>>> this is result of direct conversion from the previous buffer_head
>>>>> to bio
>>>>> API.  We don't use the page cache or the mapping anywhere else, the
>>>>> page
>>>>> is a temporary space for the associated bio.
>>>>>
>>>>> Allocate pages for all super block copies at device allocation time,
>>>>> also to avoid any later allocation problems when writing the super
>>>>> block. This simplifies the page reference tracking, but the page
>>>>> lock is
>>>>> still used as waiting mechanism for the write and write error is
>>>>> tracked
>>>>> in the page.
>>>>>
>>>>> As there is a separate page for each super block copy all can be
>>>>> submitted in parallel, as before.
>>>>
>>>> Is there any history on why we want parallel super block submission?
>>>
>>> Because it's in the transaction critical path so it affects latency of
>>> operations.
>>
>> Not exactly.
>>
>> Super block writeback happens with TRANS_STATE_UNBLOCKED status, which
>> means new transaction can already be started.
>
> You are right, in this case then I guess we can still stay with a single
> page and synchronous writeout but this needs to be explicitly mentioned
> in the changelog.

Then I would be way more happier to convert all these bio submission
path to submit_bio_wait(), which makes our error handling easier and get
rid of the super stupid endio function.

Thanks,
Qu

>
> <snip>