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 :| _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
