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

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jul 29, 2013 at 05:34:05PM -0400, Simo Sorce wrote:
> On Mon, 2013-07-29 at 23:06 +0200, Lennart Poettering wrote:
> > 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. 
> 
> If user space assume it can use 'all the space up to 15% from exhausting
> space' then it is user space that is wrong to me.
> Even w/o thin provisioning you do not want any application to
> boundlessly consume terabytes of space just because it happen to sit on
> a *big* disk.
> Applications may use heuristics to better behave in 'common' situations,
> but should limit themselves also on the max space they are going to
> consume in general (or better have admin controllable knobs to do so
> coupled with reasonable defaults).
journald provides configuration knobs to exactly set the limits.
But forcing the admin to always configure this is something that
should be avoided, and reasonable values that work OK most of the
time should be used. Those defaults (15% of available /var/log, 10% free)
may not be perfect, but they give reasonable behaviour on various
systems, large and small. This is true even on btrfs with 50%
overestimate of free space.

> > 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... 
> 
> Given the admin is the only one that knows for any given situation what
> is more important to him I do not think there is much more you can do.
> Sure you can set defaults or what not but there isn't any configuration
> that will ever be right short of something that can read minds.
> 
> What you can do is give admin knobs to tweak in user space, as well as
> in the kernel. So that applications can limit themselves based on
> configuration, lacking those knobs you need to provide mechanisms a la
> cgroups that are used to hard limit misbehaving apps that think they are
> at an all-you-can-it buffet.
Let's say that I'm downloading something in the browser, or creating a
iso image in brasero. I think it would be really awful if those
applications couldn't tell me that I don't have enough space (without
actually exhausting it and hitting a limit), like they can now.
So it's not a question of misbehaving.

Zbyszek

-- 
they are not broken. they are refucktored
                           -- alxchk