Re: btrfs loses 32-bit application compatibility after a while

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux