On Tue, Aug 29, 2017 at 1:59 PM, Peter Kjellerstedt <[email protected]> wrote: > We do have a daily job that cleans up the global sstate cache and > removes files that have not been accessed in the last ten days, but > it seems unlikely that it should remove a file that just happens to > be required again, and do it at exactly the time when that task is > building.
I guess you've already confirmed that accessing the sstate files over NFS does actually modify atime on the server (and that the filesystem on the server really does have atime support enabled, e.g. mounted with strictatime rather than relatime etc)? If access time isn't being determined reliably and sstate files are being removed 10 days after being created then that might make the race a little more likely to trigger. -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
