On Fri, Jul 14, 2023 at 11:47:39PM +0200, 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. :( Or what 32-bit code is being run in the context of koji that is NOT compiled with LFS ? Is this something silly like configure script tests not enabling LFS, but the resulting applications correctly using LFS ? With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ 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
