Hi Richard On Wed, 2026-09-16 at 09:33 +0100, Richard Purdie wrote: > 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.
Some time ago, Michael came to the exact same conclusion as you regarding this patch, but you were quicker to the list! https://git.openembedded.org/openembedded-core/commit/?id=cc07895f951140dbbffcf32d3eabf65788cc4d00 To me, this is a great sign that we’re working toward the same goal and share a common understanding. :-) One point we are still looking to clarify, however, is the reasoning behind writing to mtime when a read access occurs. According to standards, this should be handled via atime (provided the sstate directory is mounted with -o atime). In most cases, -o relatime is even sufficient and less costly. We’d argue that an NFS+ZFS server setup should work perfectly fine with standard atime and mtime updates on the Yocto side. > * 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 can leave Ceph and other cluster filesystems for a separate follow- up discussion. Our immediate goal is to improve sstate.bbclass in general; moving toward standard-compliant behavior should naturally benefit NFS, but also Ceph in the long run. However, cluster filesystems introduce unique challenges: atime must be handled carefully on the client side to avoid the massive overhead of synchronizing metadata across all nodes. In contrast, a simple single- node filesystem can afford to be more "relaxed," potentially dropping or deferring metadata updates at various points in the chain from the application to the physical medium. Do you think sstate.bbclass should stick to touching both mtime and atime, or do you agree that moving toward atime only for cache management would be the right next step for bare-metal and NFS filesystems? Thank you. Adrian > 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 (#245952): https://lists.openembedded.org/g/openembedded-core/message/245952 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]] -=-=-=-=-=-=-=-=-=-=-=-
