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

[Ric Wheeler]

On 07/29/2013 04:35 PM, Lennart Poettering wrote:
> On Mon, 29.07.13 13:48, Eric Sandeen (sandeen at redhat.com) wrote:
>
>>> Well, I am pretty sure the burden must be on the file systems to report
>>> a useful estimate free blocks value in statfs()/statvfs(). Exporting that
>>> problem to userspace and expecting userspace to work around this is just
>>> wrong. In fact, this would be quite an API breakage if applications
>>> cannot rely that the value returned is at least a rough estimate on how
>>> much data can be stored on disk.
>>>
>>> journald will scale how much disk usage it will use of /var/log/journal
>>> based on the file system size and free level. It will also module the
>>> per-service rate limit levels based on the amount of free disk space. If
>>> you break the API of statfs()/statvfs(), then you will end up break this
>>> and all programs like it.
>> Any program needs to be prepared for ENOSPC; as Ric mentioned elsewhere,
>> until you successfully write to it, it's not yours! :)  (Ok, thinp
>> running out of space won't generate ENOSPC today, either, but you see
>> my general point...)
> 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.

>
>> And how much space are we really talking about here?  If you're running
>> thin-provisioning on thin margins, especially w/o some way to automatically
>> hot-add storage, you're probably doing it wrong.
> journald will by default allow the journal files to grow to 10% of the
> filesystem size of /var/log/journal, but will make sure that 15% is
> always kept free.
>
> This really is just about finding some useful parameters for sizing
> things that are likely to just work. It's not at all about making any
> algorithms depending on that, a way to avoid ENOSPC handling or anything
> like that. It's just about finding some sensible default metircs.
>
> Lennart
>

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

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.

Ric