On 7/14/23 4:47 PM, Fabio Valentini wrote:
On Fri, Jul 14, 2023 at 10:45 PM Eric Sandeen <esandeen@xxxxxxxxxx> wrote:
On 7/14/23 6:53 AM, Florian Weimer wrote:
* Neal Gompa:
On Thu, Jul 13, 2023 at 8:29 AM Fabio Valentini <decathorpe@xxxxxxxxx> wrote:
On Thu, Jul 13, 2023 at 10:33 AM Florian Weimer <fweimer@xxxxxxxxxx> wrote:
Fedora lists are hostile to upstream collaboration via cross-posting, so
I can only forward this for your information.
This causes problems with the i686 builders.
I wonder how this only started to happen recently? Has something
changed in BTRFS with the 6.3 kernel?
This only started happening a few days after builders were rebooted at
the end of June to apply updates (and kernel 6.3 was among those
updates, as far as I can tell).
This was always possible. I'm curious as to why it took so long for us
to hit it, though.
The recommended solution is to create a new subvolume for these
environments, since the inode count is reset for each subvolume.
What about impact beyond the builders?
Are end users are expected to do this? Do we have a tool for this?
FWIW, 64 bit inodes have existed in some Linux filesystems for a very
long time. On XFS, you'll get them by default - and quickly, not after
extended use - on a filesystem of sufficient size (around 1T-2T by
default, if I remember right.)
XFS does have a hack^Wmount option to force inodes into the 32-bit
range, but just FWIW we almost never see users running into problems
with 32-bit applications (but maybe because they know about the mount
option...)
But that still raises the question - why does it look like this
started to happen pretty suddenly around June 30?
The list of updates that were applied to builders in that timeframe
doesn't raise any alarm bells (except maybe the 6.3 kernel):
(see https://pagure.io/releng/issue/11531#comment-864471)
I read the release notes for the 6.3 kernel but didn't see any
mentions of BTRFS changes that could explain this. :(
Sure - I can't speak to what might have changed in btrfs, sorry - just
saying that binaries that choke on 64 bit inodes are going to get less
and less usable over time, I think.
One thing you could consider if you're ever really in a pinch is an
ld_preload that fakes up a 32-bit inode number for i.e. stat. The vast
majority of applications don't care about the inode number at all, and
it's really kind of unfortunate to fail the whole stat call just for that.
-Eric
_______________________________________________
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
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
