On Wed, Sep 16, 2020 at 09:31:50AM -0500, Eric Sandeen wrote:
> On 9/15/20 7:29 PM, Neal Gompa wrote:
> > On Tue, Sep 15, 2020 at 7:57 PM Kevin Kofler <kevin.kof...@chello.at> wrote:
> >>
> >> Daniel Pocock wrote:
> >>> One issue I've come across is that a btrfs filesystem can only be used
> >>> on hosts with the same page size as the host that created the filesystem
> >>
> >> Ewww! That alone should disqualify btrfs as a default file system!
> >>
> >> Why does a file system depend on the kernel page size? The kernel page size
> >> is an internal implementation detail of the kernel, whereas a file system
> >> ought to be a stable interchange format that is compatible across all
> >> machines.
> >>
> >> It is unfortunate that this showstopper was not mentioned when the switch 
> >> to
> >> btrfs by default was proposed.
> 
> I'm not sure that it would have been deemed any more important than other
> concerns which were raised at the time, TBH.
> 
> > 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.
> 
> That's simply not accurate.  Handling 32/64 bit interfaces, endianness, etc
> are long-solved problems.  Longstanding lack of design or support for
> sub-page block support in a filesystem is not /at all/ the same thing.
> 
> Are there occasional endianness bugs, pointer size bugs, etc?  Sure.
> But that's different from "We did not design this."
> 
> > 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.
> 
> Sub-page block support in filesystems is not a wild, esoteric, unexpected
> feature.
> 

These kinds of problems are not really that rare across different
Filesystems.

Try creating a XFS fs on a system with 64k PAGE_SIZE and a blocksize of
64k, then try mounting that fs on a x86_64 machine. It won't work:
https://elixir.bootlin.com/linux/v5.8/source/fs/xfs/xfs_mount.c#L165
And IIRC xfs is the default for RHEL, no?


-- 
Best Regards, Benjamin Block  / Linux on IBM Z Kernel Development / IBM Systems
IBM Deutschland Research & Development GmbH    /    https://www.ibm.com/privacy
Vorsitz. AufsR.: Gregor Pillen         /        Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: AmtsG Stuttgart, HRB 243294
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

Reply via email to