On Mon, Jul 29, 2013 at 02:38:23PM -0400, Ric Wheeler wrote: > On 07/29/2013 10:18 AM, Daniel P. Berrange wrote: > >On Mon, Jul 29, 2013 at 08:01:23AM -0600, Chris Murphy wrote: > >>On Jul 29, 2013, at 6:30 AM, "Daniel P. Berrange" <berrange@xxxxxxxxxx> wrote: > >> > >>>Yep, we need to be able to report free space on filesystems, so that > >>>apps provisioning virtual machines can get an idea of how much storage > >>>they can provide to VMs without risk of over comitting. > >>> > >>>I agree that we really want the kernel, or at least a reusable shared > >>>library, to provide some kind of interface to determine this, rather > >>>than requiring every userspace app which cares to re-invent the wheel. > >>What does it mean for an app to use stat to get free space, and then > >>proceeds to create too big a VM image in a directory that has a quota > >>set? I still think apps are asking an inappropriate/unqualified question > >>by asking for volume free space, instead of what's available to them for > >>a specified path. > > From an API POV, libvirt doesn't need/care about the free space on the > >volume underlying the filesystem. We actually only care about the free > >space in a given directory that we're using for disk images. It just > >happens that we implement this using statvfs() currently. So when I > >ask for an API above, don't take this to mean I want a statvfs() that > >knows about sparse volumes. An API or syscall that provides free space > >for individual directories is fine with me. > > > > Just another note, it is never safe to assume that storage under any > file system is yours for the taking. > > If application A does a stat or statvfs() call, sees 1GB of space > left and then does a write, we could easily lose that race to any > other application. This race doesn't matter from libvirt's POV. It is just providing a mechanism via its API. It is upto the management application using libvirt to make use of the mechanism to provide a usage policy. Their usage scenario may well enable them to make certain assumptions about the storage that you could not otherwise do in a race free manner. In addition, even in more general purpose usage scenarios, it does not neccessarily matter if there is a race, because there can be a second line of defence. For example, KVM can be set to pause the VM upon ENOSPC errors, giving management application or administrator the chance to expand capacity the underlying storage and then unpause the guest. In that case checking the free space is mostly just a sanity check which serves to avoid hitting the pause-on-ENOSPC scenario too frequently. 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 :| -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
