Does your application depend on, or report, free disk space? Re: F20 Self Contained Change: OS Installer Support for LVM Thin Provisioning

Ric Wheeler rwheeler at redhat.com
Mon Jul 29 18:38:23 UTC 2013


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 at redhat.com> 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.
>
> Daniel

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.

If you want to reserve space, you need to grab the space yourself (always works 
with a large "write()" but preallocation can also help without dm-thin).

The difference with dm-thin is that all applications on all file systems backed 
by the same block pool compete for that space.

Another worry here is that preallocation is a file system concept, thinly 
provisioned storage (dm-thin or array backed), only sees proper writes so you 
need to write to space to really claim it.

Ric







More information about the devel mailing list