Mixed inline and regular extents caused by btrfs/062

Mixed inline and regular extents caused by btrfs/062

[Qu Wenruo]

Hi,

Although I understand current kernel can handle mixed inline extent with
regular extent without problem, but the idea of mixing them is still
making me quite unease.

Thus I still go testing with modify btrfs-progs to detect such problem,
and find out btrfs/062 can cause such mixed extents.

Since it's not really causing any on-disk data corruption, but just an
inconsistent behavior, I'm wondering do we really need to fix it.
(This is also the only reason why subpage has disabled inline extent
creation completely, just to prevent such problem).

Any idea on whether we should "fix" the behavior?

Thanks,
Qu

Re: Mixed inline and regular extents caused by btrfs/062

[Nikolay Borisov]

On 10.08.21 г. 8:49, Qu Wenruo wrote:
> Hi,
> 
> Although I understand current kernel can handle mixed inline extent with
> regular extent without problem, but the idea of mixing them is still
> making me quite unease.
> 
> Thus I still go testing with modify btrfs-progs to detect such problem,
> and find out btrfs/062 can cause such mixed extents.
> 
> Since it's not really causing any on-disk data corruption, but just an
> inconsistent behavior, I'm wondering do we really need to fix it.
> (This is also the only reason why subpage has disabled inline extent
> creation completely, just to prevent such problem).
> 
> Any idea on whether we should "fix" the behavior?

What do you mean by mixed inline and regular extents? AFAICS inline
extents are created when you write at the beginning of the file and the
size of the write is less than the inline extent threshold? All
subsequent writes are going to be regular extents.

> 
> Thanks,
> Qu
> 

Re: Mixed inline and regular extents caused by btrfs/062

[Qu Wenruo]

On 2021/8/10 下午3:46, Nikolay Borisov wrote:
>
>
> On 10.08.21 г. 8:49, Qu Wenruo wrote:
>> Hi,
>>
>> Although I understand current kernel can handle mixed inline extent with
>> regular extent without problem, but the idea of mixing them is still
>> making me quite unease.
>>
>> Thus I still go testing with modify btrfs-progs to detect such problem,
>> and find out btrfs/062 can cause such mixed extents.
>>
>> Since it's not really causing any on-disk data corruption, but just an
>> inconsistent behavior, I'm wondering do we really need to fix it.
>> (This is also the only reason why subpage has disabled inline extent
>> creation completely, just to prevent such problem).
>>
>> Any idea on whether we should "fix" the behavior?
>
> What do you mean by mixed inline and regular extents?

I mean, one inode has both inlined extent and regular extent.

There is an old btrfs-progs patch to detect such problems:

https://patchwork.kernel.org/project/linux-btrfs/patch/20210504062525.152540-3-wqu@suse.com/


> AFAICS inline
> extents are created when you write at the beginning of the file and the
> size of the write is less than the inline extent threshold? All
> subsequent writes are going to be regular extents.

But with above patch, the following test cases can cause btrfs-check to
report such mixed inline and regular extents:

btrfs/004
btrfs/192
btrfs/195
btrfs/205
generic/269

(Haven't yet to check the reproducibility)

Currently it won't hurt anyone, but I still don't think the mixed
behavior is expected.

Thanks,
Qu
>
>>
>> Thanks,
>> Qu
>>

Re: Mixed inline and regular extents caused by btrfs/062

[Qu Wenruo]

On 2021/8/10 下午4:09, Qu Wenruo wrote:
>
>
> On 2021/8/10 下午3:46, Nikolay Borisov wrote:
>>
>>
>> On 10.08.21 г. 8:49, Qu Wenruo wrote:
>>> Hi,
>>>
>>> Although I understand current kernel can handle mixed inline extent with
>>> regular extent without problem, but the idea of mixing them is still
>>> making me quite unease.
>>>
>>> Thus I still go testing with modify btrfs-progs to detect such problem,
>>> and find out btrfs/062 can cause such mixed extents.
>>>
>>> Since it's not really causing any on-disk data corruption, but just an
>>> inconsistent behavior, I'm wondering do we really need to fix it.
>>> (This is also the only reason why subpage has disabled inline extent
>>> creation completely, just to prevent such problem).
>>>
>>> Any idea on whether we should "fix" the behavior?
>>
>> What do you mean by mixed inline and regular extents?
>
> I mean, one inode has both inlined extent and regular extent.
>
> There is an old btrfs-progs patch to detect such problems:
>
> https://patchwork.kernel.org/project/linux-btrfs/patch/20210504062525.152540-3-wqu@suse.com/
>
>
>
>> AFAICS inline
>> extents are created when you write at the beginning of the file and the
>> size of the write is less than the inline extent threshold? All
>> subsequent writes are going to be regular extents.
>
> But with above patch, the following test cases can cause btrfs-check to
> report such mixed inline and regular extents:
>
> btrfs/004
> btrfs/192
> btrfs/195

> btrfs/205
> generic/269

Above two tests are almost 100% reproducible of such mixed extents,
especially btrfs/205 is pretty short tests.

I guess a fix would be easier to understand the problem.

Thanks,
Qu

>
> (Haven't yet to check the reproducibility)
>
> Currently it won't hurt anyone, but I still don't think the mixed
> behavior is expected.
>
> Thanks,
> Qu
>>
>>>
>>> Thanks,
>>> Qu
>>>

Re: Mixed inline and regular extents caused by btrfs/062

[Filipe Manana]

On Tue, Aug 10, 2021 at 8:06 AM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>
> Hi,
>
> Although I understand current kernel can handle mixed inline extent with
> regular extent without problem, but the idea of mixing them is still
> making me quite unease.
>
> Thus I still go testing with modify btrfs-progs to detect such problem,
> and find out btrfs/062 can cause such mixed extents.
>
> Since it's not really causing any on-disk data corruption, but just an
> inconsistent behavior, I'm wondering do we really need to fix it.
> (This is also the only reason why subpage has disabled inline extent
> creation completely, just to prevent such problem).
>
> Any idea on whether we should "fix" the behavior?

We had a discussion about this not long ago:

https://lore.kernel.org/linux-btrfs/20210506070458.168945-1-wqu@suse.com/

And yes, as you found out, it's quite easy to trigger scenarios of an
inline extent followed by non-inline extents.
Both fsstress and fsx can trigger it often, plus I remember writing
test cases that explicitly exercise those scenarios to verify that
either extent cloning works as expected or send/receive, like in
btrfs/205 for example.

Yes, there's the case triggered by fallocate, but also the case
triggered by a compressed inline extent, representing PAGE_SIZE bytes
of data, followed by other extents. This case was discussed in the
past too:

https://lore.kernel.org/linux-btrfs/20180302052254.7059-3-wqu@suse.com/

Currently this one isn't triggered anymore, but that's due to a
temporary regression in 5.14-rcs reported yesterday by Zygo, that
results in never having compressed inline extents.

I still don't consider it a problem. The code paths have been
exercised for years, reads, writes, cloning, send/receive, etc, all
work as expected as far as I know.
Having the inline extent always brings a performance benefit when
reading its data, so I don't see any advantage in changing the
behaviour - doesn't make the code faster, shorter or easy to
read/maintain.

Thanks.

>
> Thanks,
> Qu



-- 
Filipe David Manana,

“Whether you think you can, or you think you can't — you're right.”