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

[Lennart Poettering]

On Mon, 29.07.13 16:52, Ric Wheeler (rwheeler at redhat.com) wrote:

> >Oh, we don't assume it's all ours. We recheck regularly, immediately
> >before appending to the journal files, of course assuming that we are
> >not the only writers.
> 
> With thinly provisioned storage (or things like btrfs, writeable
> snapshots, etc), you will not really ever know how much space is
> really there.

Yeah, and that's an API regression.

On btrfs you can just add/remove device as you wish during runtime and
statvfs() does refelct this immediately. 

thinp should work the same. Of course, this requires that the block
layer has to pass more metadata up to the file systems than before, but
there's really nothing intrinsicly evil about that, I mean, it could be
as basic as just passing along a "provisioning perentage" or so which
the fs will simply multiply into the returned values... (Of
course it won't be that simple, but you get the concept...)

> I am starting to think that this is critical enough that we might
> want to always fully provision this - just like we would for audit
> logs....
> 
> Checking won't hurt anything, but the storage stack will lie to you
> (and honestly, we always have in many cases :)).

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... 

That the values are not perfectly accurate has been known forever. Since
file systems existed developers knew that book-keeping and stuff means
the returned valuea are slightly higher than practically reachable. And
since compressed file systems they also knew that they might be lower
than actually reachable. However, it's one thing to return bad
estimates, and it is another thing to be totally off in the woods as is
the case for thinp!

> There are some alerts that we can raise when you hit a low water
> mark for the device mapper physical pool, it would be interesting to
> talk about how you might leverage these.

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. 

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... 

Lennart

-- 
Lennart Poettering - Red Hat, Inc.