Re: [libvirt] [PATCH 2/3] Format FS pools

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.