On Sun, Feb 21, 2010 at 03:48:24PM +0100, Daniel Veillard wrote:
On Thu, Feb 18, 2010 at 05:58:06PM -0500, David Allan wrote:
> AM_CONDITIONAL([WITH_STORAGE_FS], [test "$with_storage_fs" =
"yes"])
> diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in
> index 260505e..a7751b8 100644
> --- a/include/libvirt/libvirt.h.in
> +++ b/include/libvirt/libvirt.h.in
> @@ -1053,7 +1053,8 @@ typedef enum {
> typedef enum {
> VIR_STORAGE_POOL_BUILD_NEW = 0, /* Regular build from scratch */
> VIR_STORAGE_POOL_BUILD_REPAIR = 1, /* Repair / reinitialize */
> - VIR_STORAGE_POOL_BUILD_RESIZE = 2 /* Extend existing pool */
> + VIR_STORAGE_POOL_BUILD_RESIZE = 2, /* Extend existing pool */
> + VIR_STORAGE_POOL_CREATE_FORMAT = 3 /* Format filesystem during build */
Hum, I'm not so sure, CREATE_FORMAT == BUILD_REPAIR + BUILD_RESIZE
which after all sounds a plausible combination, I would use different
bits in the field, so set VIR_STORAGE_POOL_CREATE_FORMAT to 4.
But now we need to cope with EXT3/EXT4/XFS variants, they should
probably be allocated on separate bits even if they are mutually
exclusive
This extra flag is causing the FS pool to diverge from semantics of the
other pool types. As per the comment inthe header, the
'VIR_STORAGE_POOL_BUILD_NEW'
is defined to be a full initialize of the pool from scratch. For logical pool
this pvcreate + vgcreates the data. For disk backend this writes a new empty
partition table label. For FS pools, this should be formatting the filesystem.
The type of filesystem is actually visible via the XML, so we don't need to
worry about ext3/4/etc in this context.
Regards,
Daniel
--
|: Red Hat, Engineering, London -o-
http://people.redhat.com/berrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org -o-
http://deltacloud.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|