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

Chris Murphy lists at colorremedies.com
Mon Jul 29 23:50:06 UTC 2013


On Jul 29, 2013, at 3:06 PM, Lennart Poettering <mzerqung at 0pointer.de> wrote:
> 
> Well, journald is totally fine if it is lied to in the sense that the
> values returned by statfs()/statvfs() are just estimates, and not
> precise. However, it is assumed that the values are not off by > 100% as
> they might be on thinp... 

e.g. A VM has a 1TB virtual device backed by a qcow2 file residing on a file system with 100GB free space, on a hard drive. That's > 1000%.

It's not just thinp, this has been going on for a long time. So if journald wants to know something more real in the case of thinp, why not a passthrough from real file system to virtual file system in the case of qcow2?


> Well, the point I am making is that it is wrong to ask userspace to
> handle this. Get the APIs right you expose to userspace. 

Effectively it seems for a long time now there hasn't been an API exposing the information you think user space requires. Apps using stat are asking a question of an API that by design only knows about the most immediate file system, not anything beyond which may be backing it. The request for free space in the immediate file system seems vaguely reasonable, but needing information beyond the file system seems specious.

> I mean, ultimately for me it doesn't matter I geuss, since you say
> neither the fs/block layer nor userspace should care, but that this is
> the admin's problem, but that really sounds like chickening out to
> me… 

It may be that admins are going to need better tools to assist them in monitoring before crisis events occur. But it does seem the admin shouldn't be creating 16TB qcow2 files on 1TB real backing, any more than they should do the same with thinp. They're just asking for trouble, the lie is too big.


Chris Murphy



More information about the devel mailing list