Re: btrfs and default page sizes (4k vs 64k)

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

 



On Wed, Sep 16, 2020 at 2:05 PM Tom Seewald <tseewald@xxxxxxxxx> wrote:
>
> > On Tue, Sep 15, 2020 at 7:57 PM Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:
> >
> > I hate to break it to you, but this problem is not just in
> > filesystems, it's in basically everything in the kernel. And we've had
> > variations of problems like this for years (endianness, page size,
> > pointer size, single bit vs multi-bit booleans, etc.). I've personally
> > been bitten by all of these issues in some way. This comes from the
> > fact that there's no such thing as "internal implementation detail of
> > the kernel" by design. This is the "joy" of the monorepo
> > "design"
> > where everything leaks into everything else.
> >
> > This didn't become a serious problem until Red Hat made the
> > unfortunate (though not realized at the time) mistake of switching to
> > 64k pages for ARM and POWER. We got that change in Fedora for POWER
> > but not ARM. It has led to all kinds of unfortunate problems that are
> > gradually being worked on and fixed upstream.
> >
> > Coming back to Btrfs specifically, there is work underway upstream to
> > resolve this issue. My (semi-blind) estimate is that we'll see a fix
> > in Linux 5.11, but Josef (cc'd to this email) may know more about it.
> >
> >
> >
> > --
> > 真実はいつも一つ!/ Always, there's only one truth!
>
> Frankly I'm disappointed that the response is to deflect criticism of btrfs by claiming that this is an expected issue with the kernel, and then placing the blame on Red Hat for using a larger page size. To my knowledge page size differences aren't an issue on ext4 or xfs as they default to using a 4kb block size, so saying that "it's in basically everything in the kernel" is at best inaccurate and at worst intentionally misleading.

I *expect* issues in general for stuff like this to come up when it
comes to knobs like this being turned. That does not excuse the fact
this issue exists. And it is true that all kinds of things are
impacted by those kinds of changes.

That said, there *is* work going on to resolve it *now*. I have even
asked upstream to consider just forcing 4K sizes going forward since
that is easy enough for everything to handle.

I'm annoyed in general that we still have problems like this, and I'm
even more annoyed that I basically have no way to even test or deal
with these things. We *still* do not have packager test machines, so I
can't even figure out how to craft a workaround if there is one (and I
suspect one is possible).



-- 
真実はいつも一つ!/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux