[Openstack-operators] [nova] Is verification of images in the image cache necessary?

Matthew Booth mbooth at redhat.com
Tue May 24 09:16:26 UTC 2016

During its periodic task, ImageCacheManager does a checksum of every image
in the cache. It verifies this checksum against a previously stored value,
or creates that value if it doesn't already exist.[1] Based on this
information it generates a log message if the image is corrupt, but
otherwise takes no action. Going by git, this has been the case since 2012.

The commit which added it was associated with 'blueprint
nova-image-cache-management phase 1'. I can't find this blueprint, but I
did find this page:
https://wiki.openstack.org/wiki/Nova-image-cache-management . This talks
about 'detecting images which are corrupt'. It doesn't explain why we would
want to do that, though. It also doesn't seem to have been followed through
in the last 4 years, suggesting that nobody's really that bothered.

I understand that corruption of bits on disks is a thing, but it's a thing
for more than just the image cache. I feel that this is a problem much
better solved at other layers, prime candidates being the block and
filesystem layers. There are existing robust solutions to bitrot at both of
these layers which would cover all aspects of data corruption, not just
this randomly selected slice.

As it stands, I think this code is regularly running a pretty expensive
task looking for something which will very rarely happen, only to generate
a log message which nobody is looking for. And it could be solved better in
other ways. Would anybody be sad if I deleted it?


[1] Incidentally, there also seems to be a bug in this implementation, in
that it doesn't hold the lock on the image itself at any point during the
hashing process, meaning that it cannot guarantee that the image has
finished downloading yet.
Matthew Booth
Red Hat Engineering, Virtualisation Team

Phone: +442070094448 (UK)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20160524/f30cd393/attachment.html>

More information about the OpenStack-operators mailing list