On Fri, Jul 14, 2023 at 8:48 AM Florian Weimer <fwei...@redhat.com> wrote:
>
> * Miroslav Suchý:
>
> > Dne 14. 07. 23 v 13:53 Florian Weimer napsal(a):
> >> What about impact beyond the builders?
> >>
> >> Are end users are expected to do this?  Do we have a tool for this?
> >
> > Close to zero. You have to do a really lots of builds. And keep the
> > buildroots of these (failed) builds.
>
> This is not restricted to mock or Koji, though.  There just needs to be
> one application that creates and deletes many files (or produces other
> events that causes object ID allocation in btrfs).
>
> For me it's going to be slow enough that the file system will likely be
> recreated before I encounter the 31-bit object ID limit.  But I wonder
> if that's true for everyone.
>

I don't know of a 32-bit workload that would trigger this reliably and
reasonably quickly, but if there is one, then I would be interested in
knowing about it.

We used to have something in Btrfs to mitigate this called
inode_cache, but it was turned into a no-op in 5.11 and the
documentation was removed in 5.12:
https://github.com/kdave/btrfs-progs/commit/1af37385e258aabc684484aff8e5def442ada9bb

If we have a workload example that subvolumes don't work for, then I'm
happy to advocate upstream to do something to address the problem more
directly.





--
真実はいつも一つ!/ Always, there's only one truth!
_______________________________________________
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to