The Samba-Bugzilla – Bug 9972
ccache handing out 0 byte .o files ...
Last modified: 2014-10-19 18:36:15 UTC
I had an interesting one with a partner just now - their machine had died during / shortly after compilation (I suspect) with some graphics driver lockup and hard reset. On returning all was well for some days - but (it seems) now there were several zero length (but apparently valid) files in the ccache.
Unfortunately, that meant on the next compile (of these un-changed files) - we got served up zero length .o files- which then failed to link (a zero length file is always a bad object file I think).
So - it would be just lovely to either run fsync on each file as it goes into the cache [ this was on ext4 so -in-theory- that should do some good ], and/or check for and discard zero size .o files and refuse to hand them out / clean that cache entry & force re-compilation.
Anyhow - many thanks for ccache - it saves libreoffice a ton of cycles normally ! :-)
Created attachment 9111 [details]
fixed up prototype patch
(In reply to comment #0)
> So - it would be just lovely to either run fsync on each file as it goes into
> the cache [ this was on ext4 so -in-theory- that should do some good ],
fsyncing each file would be way to slow, unfortunately.
> check for and discard zero size .o files and refuse to hand them out / clean
> that cache entry & force re-compilation.
That sounds like a good idea, though!
(In reply to comment #1)
> Created attachment 9111 [details]
> fixed up prototype patch
Thanks. I ported and applied your patch to the maint branch in 12e2badf739244dc97cad84a6fb1905ec3c4a76d (note "badf" in the hash - it's obviously a commit that fixes bad files...).
Thanks for the merge ! :-) I love the badf.
FWIW - my experience of file-data corruption under the tender ministrations of non-fsynched ext4 file-systems is that you usually end up with perfect meta-data, and (usually zero) data. So - for the next round of improvement I guess that reading the first 16 bytes or so and checking they're not all zero's might also be a useful check [ and presumably with only a small perf. impact ]. I've not seen that happen yet though in the wild.
Anyhow - thanks for ccache ... :-)
Fix included in v3.1.10.