[openstack-dev] [Cinder] About storing volume format info for filesystem-based drivers
avishay at stratoscale.com
Tue Jun 24 15:42:40 UTC 2014
One more reason why block storage management doesn't really work on file
systems. I'm OK with storing the format, but that just means you fail
migration/backup operations with different formats, right?
On Mon, Jun 23, 2014 at 6:07 PM, Trump.Zhang <zhangleiqiang at gmail.com>
> Hi, all:
> Currently, there are several filesystem-based drivers in Cinder, such
> as nfs, glusterfs, etc. Multiple format of volume other than "raw" can be
> potentially supported in these drivers, such as qcow2, raw, sparse, etc.
> However, Cinder does not store the actual format of volume and suppose
> all volumes are "raw" format. It will has or already has several problems
> as follows:
> 1. For volume migration, the generic migration implementation in
> Cinder uses the "dd" command to copy "src" volume to "dest" volume. If the
> src volume is "qcow2" format, instance will not get the right data from
> volume after the dest volume attached to instance, because the info
> returned from Cinder states that the volume's format is "raw" other than
> 2. For volume backup, the backup driver also supposes that src volumes
> are "raw" format, other format will not be supported
> Indeed, glusterfs driver has used "qemu-img info" command to judge the
> format of volume. However, as the comment from Duncan in  says, this
> auto detection method has many possible error / exploit vectors. Because if
> the beginning content of a "raw" volume happens to a "qcow2" disk, auto
> detection method will judge this volume to be a "qcow2" volume wrongly.
> I proposed that the "format" info should be added to "admin_metadata"
> of volumes, and enforce it on all operations, such as create, copy, migrate
> and retype. The "format" will be only set / updated for filesystem-based
> drivers, other drivers will not contains this metadata and have a default
> "raw" format.
> Any advice?
>  https://review.openstack.org/#/c/100529/
> Best Regards
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev