Bug #1775

sunstone import does not fill in the source till successful md5 check

Added by Gregory McLean over 8 years ago. Updated over 7 years ago.

Status:ClosedStart date:02/21/2013
Priority:NormalDue date:
Assignee:-% Done:


Category:Drivers - Storage
Target version:-
Resolution: Pull request:
Affected Versions:OpenNebula 3.8


$ oneimage list
17 oneadmin oneadmin CentOS Server 6 user_ds 578M OS No err 0
$ oneimage show 17
PATH : /var/tmp/thin-body20130221-3166-1jei97y-0

oned.log:Thu Feb 21 11:38:01 2013 [ImM][E]: cp: Command "/var/lib/one/remotes/datastore/fs/../downloader.sh --md5 e53408073c6ab9b917f2fb75b86f4160 /var/tmp/thin-body20130221-3166-1jei97y-0 /var/lib/one/datastores/100/64d9e6626debdd49bb9d06564287bef2" failed: Hash does not match

But wait...

ls lh /var/lib/one/datastores/100/64d9e6626debdd49bb9d06564287bef2
1 oneadmin cloud 10G Feb 21 11:38 /var/lib/one/datastores/100/64d9e6626debdd49bb9d06564287bef2

So... if that image gets deleted from the database, the 10 gigs it copied to the local drive will remain. and with no obvious indication of which file is which image in the database without poking around in the database matching things up, one could quickly run out of space in the datastore and wind up with quite a mess to clean up.

Maybe when the downloader starts unbziping the image it could fill out the source entry in the database so on failure one could just remove the entry and have the broken image removed as well?

Related issues

Duplicates Bug #1573: If an image download fails, the file is never deleted fro... New 10/23/2012


#1 Updated by Ruben S. Montero about 8 years ago

  • Category set to Drivers - Storage

#2 Updated by Ruben S. Montero about 8 years ago

  • Status changed from New to Closed

#3 Updated by Stefan Kooman over 7 years ago

The status has changed from "new" to "closed". Has this issue been fixed? If so, in what version? I've noticed I'm suffering from the same bug (opennebula 4.2). At the moment it seems impossible to check which image (file on disk) is in "error state" and which image is healthy (ready, used, etc.). If an extra field with "filename" would be created in the mysql database table "image_pool" it's possible to check wich image is not in the database and therefore can be safely removed from disk.

Also available in: Atom PDF