Fix race conditions between imagebackend and imagecache
The race may occur in the situation:
* There is a base file that is not used for a long time enough
to be removed by imagecache.
* imagebackend is provisioning a virtual disk from the base file.
* imagecache is removing the base file.
Then, the base file is removed even though it is about to be used.
To fix this, these changes are in this patch:
* A new function imagecache.refresh_timestamp(base_file) updates
the owner and mtime of the base file with the lock dedicated
to the base file.
* imagebacked calls refresh_timestamp(base_file) before provision
a disk from the base file.
* imagecache.ImageCacheManager._remove_base_file(base_file) uses
the same lock as used by refresh_timestamp()
Reviewed: https:/ /review. openstack. org/61075 /git.openstack. org/cgit/ openstack/ nova/commit/ ?id=2593469103a a7d9d2bcb759b78 d5f8637911a1e0
Committed: https:/
Submitter: Jenkins
Branch: master
commit 2593469103aa7d9 d2bcb759b78d5f8 637911a1e0
Author: Arata Notsu <email address hidden>
Date: Tue Dec 3 18:27:26 2013 +0900
Fix race conditions between imagebackend and imagecache
The race may occur in the situation:
* There is a base file that is not used for a long time enough
to be removed by imagecache.
* imagebackend is provisioning a virtual disk from the base file.
* imagecache is removing the base file.
Then, the base file is removed even though it is about to be used.
To fix this, these changes are in this patch:
* A new function imagecache. refresh_ timestamp( base_file) updates timestamp( base_file) before provision ImageCacheManag er._remove_ base_file( base_file) uses
the owner and mtime of the base file with the lock dedicated
to the base file.
* imagebacked calls refresh_
a disk from the base file.
* imagecache.
the same lock as used by refresh_timestamp()
Closes-Bug: #1256838 a2c4532fb3a7386 3d649d02782
Change-Id: I7c897cf6071d87