[libvirt] [PATCH 2/2] Add fs pool formatting

Daniel P. Berrange berrange at redhat.com
Mon May 17 15:54:55 UTC 2010


On Fri, May 14, 2010 at 08:00:52AM -0600, Eric Blake wrote:
> On 05/13/2010 08:18 PM, David Allan wrote:
> > * This patch adds the ability to make the filesystem for a filesystem
> >   pool during a pool build.
> > 
> >   The patch adds two new flags, probe and overwrite, to control when
> >   mkfs gets executed.  By default, the patch preserves the current
> >   behavior, i.e., if no flags are specified, pool build on a
> >   filesystem pool only makes the directory on which the filesystem
> >   will be mounted.
> > 
> >  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_REPAIR = (1 << 0), /* Repair / reinitialize */
> > +  VIR_STORAGE_POOL_BUILD_RESIZE = (1 << 1),  /* Extend existing pool */
> > +  VIR_STORAGE_POOL_BUILD_PROBE = (1 << 2),  /* Probe for existing pool */
> > +  VIR_STORAGE_POOL_BUILD_OVERWRITE = (1 << 3)  /* Overwrite data */
> 
> Can one specify both probe and overwrite, or are they mutually
> exclusive?  Maybe it makes sense to allow both - don't overwrite the
> filesystem if it is not already of the correct type, but if it is the
> correct type, then erase it and start from scratch (contrasted with
> probe in isolation doing nothing if the right type is present but
> overwriting on all other types).

All of these flags are mutually exclusive really, but we don't
want to use a sequence for them, since we need to allow for 
some non-mutually exclusive flags later.


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




More information about the libvir-list mailing list