Bug 10857

Summary: sstate: .siginfo files are not accessed from local or NFS-mounted SSTATE_MIRROR
Product: [Build System, Metadata & Runtime] OE-Core Reporter: Denys Dmytriyenko <denis>
Component: configurationAssignee: Ed Bartosh <eduard.bartosh>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: Medium    
Version: unspecified   
Target Milestone: 2.3   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: No (bug/feature does not impact docs)

Description Denys Dmytriyenko 2016-12-24 02:40:07 UTC 
It appears that .siginfo files are not being accessed from local or NFS-mounted SSTATE_MIRROR (file://), so their timestamp never gets updated. If you periodically clean SSTATE_MIRROR based on access time, they get deleted, even though they are still being used, leading to errors like:

WARNING: quilt-native-0.64-r0 do_populate_sysroot_setscene: Failed to fetch URL file://Ubuntu-16.04/52/sstate:quilt-native:x86_64-linux:0.64:r0:x86_64:3:5227556845cbc224f05726d1633de4e5_populate_sysroot.tgz.siginfo, attempting MIRRORS if available 
ERROR: quilt-native-0.64-r0 do_populate_sysroot_setscene: Fetcher failure: Unable to find file file://Ubuntu-16.04/52/sstate:quilt-native:x86_64-linux:0.64:r0:x86_64:3:5227556845cbc224f05726d1633de4e5_populate_sysroot.tgz.siginfo anywhere. The paths that were searched were: 

In this case, corresponding file://Ubuntu-16.04/52/sstate:quilt-native:x86_64-linux:0.64:r0:x86_64:3:5227556845cbc224f05726d1633de4e5_populate_sysroot.tgz is still there, but not its .siginfo

Everything works fine for HTTP-based SSTATE_MIRROR, because .tgz and their corresponding .siginfo files are being downloaded, updating both files timestamps on the server.

So, regardless of SSTATE_MIRROR access protocol, when .tgz is being used, corresponding .siginfo file should probably be "touch"-ed to update it's timestamp to prevent this issue.
Comment 1 Denys Dmytriyenko 2017-02-17 00:45:56 UTC 
Any updates or comments on this?
Comment 2 Ed Bartosh 2017-02-20 12:06:39 UTC 
I'm sorry, I haven't looked at this yet.
I'm planning to do it after I fix all 2.3 M3 bugs assigned to me with higher priority.
Comment 3 Ed Bartosh 2017-02-23 18:05:17 UTC 
Can you provide more info please? How your sstate NFS share is mounted? Did you use noatime or relatime option to mount it?
Comment 4 Denys Dmytriyenko 2017-03-01 03:35:02 UTC 
It uses "relatime" by default. Should I try something else?
Comment 5 Ed Bartosh 2017-03-01 10:08:42 UTC 
No, you shouldn't unless you want atime to be updated immediately when file is accessed. relatime is delaying atime updates as far as I know.

I reproduced this bug with strictatime mount option. Hopefully will fix it soon.
Comment 8 Ed Bartosh 2017-03-10 18:31:36 UTC 
The fix has been merged to oe-core and poky master branches.
Comment 9 Denys Dmytriyenko 2017-03-10 18:33:36 UTC 
Thanks!