openstack team mailing list archive

["Daniel P. Berrange" <berrange@xxxxxxxxxx>]

On Tue, Jul 03, 2012 at 11:01:11AM +0100, John Garbutt wrote:
> Sorry to go back in the tread, but just wanted to ask a possibly dumb question.
> 
> > Daniel P. Berrange wrote:
> > In the particular case of the qemu-img command described in earlier in this
> > thread, I'm not convinced we need a new option. Instead of using /tmp
> > when extracting a snapshot from an existing disk image, it could just use the
> > path where the source image already resides. ie the existing
> > FLAGS.instances_path directory, which can be assumed to be a suitably large
> > persistent data store.
> 
> Would that not be a bad idea for those having FLAGS.instances_path on
> a shared file system, like gluster?

Well it would mean more I/O to that filesystem yes. Whether this is bad or
not depends on whether there is an alternative. If users of gluster also
have a large local scratch space area then, we could make it possible to
use that, if they don't have a local scratch space, then this is a
reasonable usage.

This would suggest there's a potential use case for a new config parameter
FLAGS.local_scratch_path, whose default value matches FLAGS.instances_path
if not set.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|