[openstack-dev] [Cinder] About storing volume format info for filesystem-based drivers

John Griffith john.griffith at solidfire.com
Tue Jun 24 15:55:56 UTC 2014


On Tue, Jun 24, 2014 at 9:42 AM, Avishay Traeger <avishay at stratoscale.com>
wrote:

> 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?
>

​+1... sooooo nice that somebody else said it for me this time!!

We need to make sure this is completely abstracted from end-user and the
manager can make the right decisions (ie implement a way to work from one
to the other)​.

>
>
> On Mon, Jun 23, 2014 at 6:07 PM, Trump.Zhang <zhangleiqiang at gmail.com>
> wrote:
>
>> 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
>> "qcow2"
>>     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 [1] 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?
>>
>> [1] https://review.openstack.org/#/c/100529/
>>
>> --
>> -------------------
>> Best Regards
>>
>> Trump.Zhang
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140624/8f46a357/attachment.html>


More information about the OpenStack-dev mailing list