Re: [openstack-dev] [Cinder] About storing volume format info for filesystem-based drivers
On Tue, Jun 24, 2014 at 9:56 AM, Duncan Thomas wrote: > On 24 June 2014 16:42, Avishay Traeger 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? > > Actually I think storing the format *fixes* those cases, since the > driver knows what the source format is to get a raw stream of bytes > out. It was in trying to fix backup that this problem was found. > Yes, but I was also trying to point out this shouldn't be done in the driver... but at this point maybe IRC is a better forum to discuss the impl? > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] About storing volume format info for filesystem-based drivers
On Tue, Jun 24, 2014 at 9:42 AM, Avishay Traeger 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... so 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 > 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@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] About storing volume format info for filesystem-based drivers
On 24 June 2014 16:42, Avishay Traeger 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? Actually I think storing the format *fixes* those cases, since the driver knows what the source format is to get a raw stream of bytes out. It was in trying to fix backup that this problem was found. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] About storing volume format info for filesystem-based drivers
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 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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] About storing volume format info for filesystem-based drivers
On 06/23/2014 11:07 AM, Trump.Zhang 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/ > I agree with the concerns here, and I think storing the creation format is the right idea. Please file a blueprint describing the fix and I'll help review from there. Eric ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] About storing volume format info for filesystem-based drivers
Write a blueprint and a patch... On 23 June 2014 16:07, Trump.Zhang 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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Duncan Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Cinder] About storing volume format info for filesystem-based drivers
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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
