https://sourceware.org/bugzilla/show_bug.cgi?id=30612
--- Comment #4 from Dominique Martinet <rfhn.fhbrrjnzeneqpf at noclue dot notk.org> --- > Is this truly a practical problem? Virtually every space-constrained system > makes use of compressed firmware images, or has readily access to that > tecnology. We're using plain ext4 for the root file system at $work, as it's not read-only. Since this change I've been pushing for btrfs with compression enabled, but it's a workaround at best. Afaik, container images layers are also stored uncompressed for example, so there's plenty of "at scale" effect too... > I ask, because the alleged "fix" [1] to this space issue introduced a > regression [2] which effectively banned GNU/Linux from systems with larger > pagesizes, which, contrary to the assumption in the commit, exist > commercially and in large numbers. That's not a fix; it wasn't even considered for arm64 because larger pages are known to be used there. The fix was described in #28824 (make multiple mappings), but nobody's gone out of their way to implement it yet (for my part, mostly because the workaround is cheaper to implement and $work priorities aren't aligned with "doing the right thing") -- You are receiving this mail because: You are on the CC list for the bug.
