On Wed, 2026-09-16 at 08:05 +0000, Adrian Freihofer via lists.openembedded.org wrote: > Hi everyone, > > Thank you for the discussion in the patch review meeting. After > discussing this further with Michael, I’m providing a summary of the > technical details and the various perspectives shared: > > * Release Timing: Given how close we are to the next release, we have > decided to put this patch series on hold. Modifying these crucial > lines of code carries a risk that is not feasible at this stage. We > will revisit the implementation and timing immediately after the > release. > * Architectural Goal & Cache Management: Our primary objective is to > move toward standard mtime and atime behavior. Currently, non- > standard usage makes it difficult for different environments to > interact with the cache as expected. Adhering to standard behavior > allows for better cache management, as it for example provides the > necessary telemetry to identify objects that are "old" but still > actively "in use." > * We will have a look a the sstate-cache-management.py script and > check if the script can be extended with some prune features which > we need on our infrastructure. > > Follow-up Discussion: We also recognize the specific performance > challenges with Kubernetes CephFS (particularly the server-side > propagation of atime changes). While this is a key driver for these > improvements, we will address the specific CephFS optimizations and > related performance impacts in a follow-up discussion and dedicated > discussion to keep the current architectural changes focused.
Thanks for the summary Adrian. Just to expand on a couple of details: * I did recently change some of this code with the intention of making it consistent with atime, mtime, file extensions and symlinks. The previous version was a horrible mix of different behaviours and sstate cache management was struggling as a result. This was likely a cause of some intermittent AB failures. * Whilst this may improve cephfs, we're worried about how this may interact with zfs+NFS or ext*+NFS and the possibility of noatime, limited (re)write access and other mount options. We do limit the areas we interact with shared data usage but this is one of the areas we do and we need to be careful about changes here as a result. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#245937): https://lists.openembedded.org/g/openembedded-core/message/245937 Mute This Topic: https://lists.openembedded.org/mt/121194864/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
