> On Tue, Sep 15, 2020 at 7:57 PM Kevin Kofler <kevin.kofler(a)chello.at> 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. _______________________________________________ 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
