mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2024-10-08 23:35:57 +00:00
4cd7d220c9
https://bugzilla.redhat.com/show_bug.cgi?id=1233003 Commit id 'fdda3760' only managed a symptom where it was possible to create a file in a pool without libvirt's knowledge, so it was reverted. The real fix is to have all the createVol API's which actually create a volume (disk, logical, zfs) and the buildVol API's which handle the real creation of some volume file (fs, rbd, sheepdog) manage deleting any volume which they create when there is some sort of error in processing the volume. This way the onus isn't left up to the storage_driver to determine whether the buildVol failure was due to some failure as a result of adjustments made to the volume after creation such as getting sizes, changing ownership, changing volume protections, etc. or simple a failure in creation. Without needing to consider that the volume has to be removed, the buildVol failure path only needs to remove the volume from the pool. This way if a creation failed due to duplicate name, libvirt wouldn't remove a volume that it didn't create in the pool target. |
||
|---|---|---|
| .. | ||
| parthelper.c | ||
| storage_backend_disk.c | ||
| storage_backend_disk.h | ||
| storage_backend_fs.c | ||
| storage_backend_fs.h | ||
| storage_backend_gluster.c | ||
| storage_backend_gluster.h | ||
| storage_backend_iscsi.c | ||
| storage_backend_iscsi.h | ||
| storage_backend_logical.c | ||
| storage_backend_logical.h | ||
| storage_backend_mpath.c | ||
| storage_backend_mpath.h | ||
| storage_backend_rbd.c | ||
| storage_backend_rbd.h | ||
| storage_backend_scsi.c | ||
| storage_backend_scsi.h | ||
| storage_backend_sheepdog.c | ||
| storage_backend_sheepdog.h | ||
| storage_backend_zfs.c | ||
| storage_backend_zfs.h | ||
| storage_backend.c | ||
| storage_backend.h | ||
| storage_driver.c | ||
| storage_driver.h | ||