BIG_METADATA - dont understand fix or implications

BIG_METADATA - dont understand fix or implications

[Peter Allebone]

Hi there,

Apologies in advance, I dont understand how I am affected by this issue here:

https://lore.kernel.org/linux-btrfs/20220623142641.GQ20633@twin.jikos.cz/

I have a problem where if I run "sudo btrfs inspect-internal
dump-super /dev/sdbx" on some disks it  shows the BIG_METADATA flag
and some disks it does not. I posted about it here on reddit:

https://www.reddit.com/r/btrfs/comments/vo8run/why_does_the_inspectinternal_command_not_show_big/

My concern is what effect does this have and how do I fix it, once the
patch makes its way down to me. Is there any concern with data on that
disk changing in an unexpected way?

Many thanks for any insight you can shed. I did read the thread but
was not able to easily follow or understand what was implied or what
would happen to someone affected by the issue.

Thank you again in advance. Sorry for emailing in. Hope that is ok. I
was just concerned.

Kind regards
Peter

Re: BIG_METADATA - dont understand fix or implications

[Nikolay Borisov]

On 12.07.22 г. 15:24 ч., Peter Allebone wrote:
> Hi there,
> 
> Apologies in advance, I dont understand how I am affected by this issue here:
> 
> https://lore.kernel.org/linux-btrfs/20220623142641.GQ20633@twin.jikos.cz/
> 
> I have a problem where if I run "sudo btrfs inspect-internal
> dump-super /dev/sdbx" on some disks it  shows the BIG_METADATA flag
> and some disks it does not. I posted about it here on reddit:
> 
> https://www.reddit.com/r/btrfs/comments/vo8run/why_does_the_inspectinternal_command_not_show_big/
> 
> My concern is what effect does this have and how do I fix it, once the
> patch makes its way down to me. Is there any concern with data on that
> disk changing in an unexpected way?
> 
> Many thanks for any insight you can shed. I did read the thread but
> was not able to easily follow or understand what was implied or what
> would happen to someone affected by the issue.
> 
> Thank you again in advance. Sorry for emailing in. Hope that is ok. I
> was just concerned.

If you are using recent kernels i.e stable ones then there are no 
practical implications, because as soon as you mount the filesystem with 
a kernel which has the patch this flag would be correctly set. As said 
in the changelog of the patch this can be a potential problem for 
pre-3.10 kernels (very old) so the conclusion is you have nothing too 
worry about.

> 
> Kind regards
> Peter

Re: BIG_METADATA - dont understand fix or implications

[Qu Wenruo]

On 2022/7/12 20:24, Peter Allebone wrote:
> Hi there,
>
> Apologies in advance, I dont understand how I am affected by this issue here:
>
> https://lore.kernel.org/linux-btrfs/20220623142641.GQ20633@twin.jikos.cz/
>
> I have a problem where if I run "sudo btrfs inspect-internal
> dump-super /dev/sdbx" on some disks it  shows the BIG_METADATA flag
> and some disks it does not. I posted about it here on reddit:
>
> https://www.reddit.com/r/btrfs/comments/vo8run/why_does_the_inspectinternal_command_not_show_big/
>
> My concern is what effect does this have and how do I fix it, once the
> patch makes its way down to me. Is there any concern with data on that
> disk changing in an unexpected way?

BIG_METADATA is a legacy flag to indicate the fs has nodesize larger
than sectorsize.

But the truth is, we shouldn't need the flag from the very beginning.

Just like the days before subpage, if the kernel detects some thing like
nodesize/sectorsize not supported, the kernel should rejects the fs with
proper dmesg output.


>
> Many thanks for any insight you can shed. I did read the thread but
> was not able to easily follow or understand what was implied or what
> would happen to someone affected by the issue.

For now, you don't even need to bother the flags.

No matter if we have the flag, kernel will do the correct thing to
handle the nodesize/sectorsize combination.

And since there is at least one end user concerning about this, I
strongly believe we should deprecate the flag, and make it disappear for
good.

Thanks,
Qu

>
> Thank you again in advance. Sorry for emailing in. Hope that is ok. I
> was just concerned.
>
> Kind regards
> Peter

Re: BIG_METADATA - dont understand fix or implications

[Qu Wenruo]

On 2022/7/12 21:05, Nikolay Borisov wrote:
>
>
> On 12.07.22 г. 15:24 ч., Peter Allebone wrote:
>> Hi there,
>>
>> Apologies in advance, I dont understand how I am affected by this
>> issue here:
>>
>> https://lore.kernel.org/linux-btrfs/20220623142641.GQ20633@twin.jikos.cz/
>>
>> I have a problem where if I run "sudo btrfs inspect-internal
>> dump-super /dev/sdbx" on some disks it  shows the BIG_METADATA flag
>> and some disks it does not. I posted about it here on reddit:
>>
>> https://www.reddit.com/r/btrfs/comments/vo8run/why_does_the_inspectinternal_command_not_show_big/
>>
>>
>> My concern is what effect does this have and how do I fix it, once the
>> patch makes its way down to me. Is there any concern with data on that
>> disk changing in an unexpected way?
>>
>> Many thanks for any insight you can shed. I did read the thread but
>> was not able to easily follow or understand what was implied or what
>> would happen to someone affected by the issue.
>>
>> Thank you again in advance. Sorry for emailing in. Hope that is ok. I
>> was just concerned.
>
> If you are using recent kernels i.e stable ones then there are no
> practical implications, because as soon as you mount the filesystem with
> a kernel which has the patch this flag would be correctly set. As said
> in the changelog of the patch this can be a potential problem for
> pre-3.10 kernels (very old) so the conclusion is you have nothing too
> worry about.

I just went checking v3.9 and v3.5, if there is no such flag, kernel
will still mount the fs and setting the flag.

So it doesn't seem to cause any compatibility problems at all.

Thanks,
Qu
>
>>
>> Kind regards
>> Peter

Re: BIG_METADATA - dont understand fix or implications

[Nikolay Borisov]

On 12.07.22 г. 16:13 ч., Qu Wenruo wrote:
> 
> 
> On 2022/7/12 21:05, Nikolay Borisov wrote:
>>
>>
>> On 12.07.22 г. 15:24 ч., Peter Allebone wrote:
>>> Hi there,
>>>
>>> Apologies in advance, I dont understand how I am affected by this
>>> issue here:
>>>
>>> https://lore.kernel.org/linux-btrfs/20220623142641.GQ20633@twin.jikos.cz/ 
>>>
>>>
>>> I have a problem where if I run "sudo btrfs inspect-internal
>>> dump-super /dev/sdbx" on some disks it  shows the BIG_METADATA flag
>>> and some disks it does not. I posted about it here on reddit:
>>>
>>> https://www.reddit.com/r/btrfs/comments/vo8run/why_does_the_inspectinternal_command_not_show_big/ 
>>>
>>>
>>>
>>> My concern is what effect does this have and how do I fix it, once the
>>> patch makes its way down to me. Is there any concern with data on that
>>> disk changing in an unexpected way?
>>>
>>> Many thanks for any insight you can shed. I did read the thread but
>>> was not able to easily follow or understand what was implied or what
>>> would happen to someone affected by the issue.
>>>
>>> Thank you again in advance. Sorry for emailing in. Hope that is ok. I
>>> was just concerned.
>>
>> If you are using recent kernels i.e stable ones then there are no
>> practical implications, because as soon as you mount the filesystem with
>> a kernel which has the patch this flag would be correctly set. As said
>> in the changelog of the patch this can be a potential problem for
>> pre-3.10 kernels (very old) so the conclusion is you have nothing too
>> worry about.
> 
> I just went checking v3.9 and v3.5, if there is no such flag, kernel
> will still mount the fs and setting the flag.
> 
> So it doesn't seem to cause any compatibility problems at all.

But that's the point, fs created post 3.10 should not be mountable by 
pre 3.10 because they'd see an unknown flag.

> 
> Thanks,
> Qu
>>
>>>
>>> Kind regards
>>> Peter

Re: BIG_METADATA - dont understand fix or implications

[Qu Wenruo]

On 2022/7/12 21:18, Nikolay Borisov wrote:
>
>
> On 12.07.22 г. 16:13 ч., Qu Wenruo wrote:
>>
>>
>> On 2022/7/12 21:05, Nikolay Borisov wrote:
>>>
>>>
>>> On 12.07.22 г. 15:24 ч., Peter Allebone wrote:
>>>> Hi there,
>>>>
>>>> Apologies in advance, I dont understand how I am affected by this
>>>> issue here:
>>>>
>>>> https://lore.kernel.org/linux-btrfs/20220623142641.GQ20633@twin.jikos.cz/
>>>>
>>>>
>>>> I have a problem where if I run "sudo btrfs inspect-internal
>>>> dump-super /dev/sdbx" on some disks it  shows the BIG_METADATA flag
>>>> and some disks it does not. I posted about it here on reddit:
>>>>
>>>> https://www.reddit.com/r/btrfs/comments/vo8run/why_does_the_inspectinternal_command_not_show_big/
>>>>
>>>>
>>>>
>>>> My concern is what effect does this have and how do I fix it, once the
>>>> patch makes its way down to me. Is there any concern with data on that
>>>> disk changing in an unexpected way?
>>>>
>>>> Many thanks for any insight you can shed. I did read the thread but
>>>> was not able to easily follow or understand what was implied or what
>>>> would happen to someone affected by the issue.
>>>>
>>>> Thank you again in advance. Sorry for emailing in. Hope that is ok. I
>>>> was just concerned.
>>>
>>> If you are using recent kernels i.e stable ones then there are no
>>> practical implications, because as soon as you mount the filesystem with
>>> a kernel which has the patch this flag would be correctly set. As said
>>> in the changelog of the patch this can be a potential problem for
>>> pre-3.10 kernels (very old) so the conclusion is you have nothing too
>>> worry about.
>>
>> I just went checking v3.9 and v3.5, if there is no such flag, kernel
>> will still mount the fs and setting the flag.
>>
>> So it doesn't seem to cause any compatibility problems at all.
>
> But that's the point, fs created post 3.10 should not be mountable by
> pre 3.10 because they'd see an unknown flag.

Oh, got it now.

Although the introduction of that flag is a little older, in v3.4. (v3.3
doesn't have it).

Thanks,
Qu
>
>>
>> Thanks,
>> Qu
>>>
>>>>
>>>> Kind regards
>>>> Peter

Re: BIG_METADATA - dont understand fix or implications

[Nikolay Borisov]

On 12.07.22 г. 16:22 ч., Qu Wenruo wrote:
> 
> 
> On 2022/7/12 21:18, Nikolay Borisov wrote:
>>
>>
>> On 12.07.22 г. 16:13 ч., Qu Wenruo wrote:
>>>
>>>
>>> On 2022/7/12 21:05, Nikolay Borisov wrote:
>>>>
>>>>
>>>> On 12.07.22 г. 15:24 ч., Peter Allebone wrote:
>>>>> Hi there,
>>>>>
>>>>> Apologies in advance, I dont understand how I am affected by this
>>>>> issue here:
>>>>>
>>>>> https://lore.kernel.org/linux-btrfs/20220623142641.GQ20633@twin.jikos.cz/ 
>>>>>
>>>>>
>>>>>
>>>>> I have a problem where if I run "sudo btrfs inspect-internal
>>>>> dump-super /dev/sdbx" on some disks it  shows the BIG_METADATA flag
>>>>> and some disks it does not. I posted about it here on reddit:
>>>>>
>>>>> https://www.reddit.com/r/btrfs/comments/vo8run/why_does_the_inspectinternal_command_not_show_big/ 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> My concern is what effect does this have and how do I fix it, once the
>>>>> patch makes its way down to me. Is there any concern with data on that
>>>>> disk changing in an unexpected way?
>>>>>
>>>>> Many thanks for any insight you can shed. I did read the thread but
>>>>> was not able to easily follow or understand what was implied or what
>>>>> would happen to someone affected by the issue.
>>>>>
>>>>> Thank you again in advance. Sorry for emailing in. Hope that is ok. I
>>>>> was just concerned.
>>>>
>>>> If you are using recent kernels i.e stable ones then there are no
>>>> practical implications, because as soon as you mount the filesystem 
>>>> with
>>>> a kernel which has the patch this flag would be correctly set. As said
>>>> in the changelog of the patch this can be a potential problem for
>>>> pre-3.10 kernels (very old) so the conclusion is you have nothing too
>>>> worry about.
>>>
>>> I just went checking v3.9 and v3.5, if there is no such flag, kernel
>>> will still mount the fs and setting the flag.
>>>
>>> So it doesn't seem to cause any compatibility problems at all.
>>
>> But that's the point, fs created post 3.10 should not be mountable by
>> pre 3.10 because they'd see an unknown flag.
> 
> Oh, got it now.
> 
> Although the introduction of that flag is a little older, in v3.4. (v3.3
> doesn't have it).

Yes you are right, commit 727011e07cbd ("Btrfs: allow metadata blocks 
larger than the page size") landed in 3.4 not 3.10, so the changelog of 
the patch needs to be changed.


> 
> Thanks,
> Qu
>>
>>>
>>> Thanks,
>>> Qu
>>>>
>>>>>
>>>>> Kind regards
>>>>> Peter

Re: BIG_METADATA - dont understand fix or implications

[Peter Allebone]

Ok I understand. Thank you for your time and effort, and reply. Hope
you have a great day :)

Kind regards
Peter

On Tue, Jul 12, 2022 at 9:30 AM Nikolay Borisov <nborisov@suse.com> wrote:
>
>
>
> On 12.07.22 г. 16:22 ч., Qu Wenruo wrote:
> >
> >
> > On 2022/7/12 21:18, Nikolay Borisov wrote:
> >>
> >>
> >> On 12.07.22 г. 16:13 ч., Qu Wenruo wrote:
> >>>
> >>>
> >>> On 2022/7/12 21:05, Nikolay Borisov wrote:
> >>>>
> >>>>
> >>>> On 12.07.22 г. 15:24 ч., Peter Allebone wrote:
> >>>>> Hi there,
> >>>>>
> >>>>> Apologies in advance, I dont understand how I am affected by this
> >>>>> issue here:
> >>>>>
> >>>>> https://lore.kernel.org/linux-btrfs/20220623142641.GQ20633@twin.jikos.cz/
> >>>>>
> >>>>>
> >>>>>
> >>>>> I have a problem where if I run "sudo btrfs inspect-internal
> >>>>> dump-super /dev/sdbx" on some disks it  shows the BIG_METADATA flag
> >>>>> and some disks it does not. I posted about it here on reddit:
> >>>>>
> >>>>> https://www.reddit.com/r/btrfs/comments/vo8run/why_does_the_inspectinternal_command_not_show_big/
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> My concern is what effect does this have and how do I fix it, once the
> >>>>> patch makes its way down to me. Is there any concern with data on that
> >>>>> disk changing in an unexpected way?
> >>>>>
> >>>>> Many thanks for any insight you can shed. I did read the thread but
> >>>>> was not able to easily follow or understand what was implied or what
> >>>>> would happen to someone affected by the issue.
> >>>>>
> >>>>> Thank you again in advance. Sorry for emailing in. Hope that is ok. I
> >>>>> was just concerned.
> >>>>
> >>>> If you are using recent kernels i.e stable ones then there are no
> >>>> practical implications, because as soon as you mount the filesystem
> >>>> with
> >>>> a kernel which has the patch this flag would be correctly set. As said
> >>>> in the changelog of the patch this can be a potential problem for
> >>>> pre-3.10 kernels (very old) so the conclusion is you have nothing too
> >>>> worry about.
> >>>
> >>> I just went checking v3.9 and v3.5, if there is no such flag, kernel
> >>> will still mount the fs and setting the flag.
> >>>
> >>> So it doesn't seem to cause any compatibility problems at all.
> >>
> >> But that's the point, fs created post 3.10 should not be mountable by
> >> pre 3.10 because they'd see an unknown flag.
> >
> > Oh, got it now.
> >
> > Although the introduction of that flag is a little older, in v3.4. (v3.3
> > doesn't have it).
>
> Yes you are right, commit 727011e07cbd ("Btrfs: allow metadata blocks
> larger than the page size") landed in 3.4 not 3.10, so the changelog of
> the patch needs to be changed.
>
>
> >
> > Thanks,
> > Qu
> >>
> >>>
> >>> Thanks,
> >>> Qu
> >>>>
> >>>>>
> >>>>> Kind regards
> >>>>> Peter