On Wed, 2026-09-16 at 11:39 +0000, Freihofer, Adrian wrote: > 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=cc07895f951 > 140dbbffcf32d3eabf65788cc4d00 > 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.
>From a theoretical standpoint you can argue this. Real world experience suggests things aren't this straightforward. The code was a mix and in the end I just standardised it to do everything consistently. I know there have been requests and code for mtime in the past, at least partially. Whether this was a bug with atime handling is unclear. We don't currently document you must have sstate mounted with atime, or working atime. Perhaps we should, I don't know. I do know just atime at the filesystem level alone hasn't been enough in the past. > > 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? Touching mtime and atime was the least worst option last time I worked on the code. If we want to drop mtime, we need to have a pretty good feeling that usecases won't break. I've therefore tried to at least articulate what some of those are. We'd need to look at what the autobuilder is doing, how some of our other users use things in CI and so on to see what impact that would have. Getting people to do this kind of review is hard work :/. Just saying it should work in theory and talking about standards isn't really enough in this case. So I guess I'm saying it may be possible to change but we do need a bit more analysis and buy in from others for the change than what we have right now. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#245973): https://lists.openembedded.org/g/openembedded-core/message/245973 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]] -=-=-=-=-=-=-=-=-=-=-=-
