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

[Eric Sandeen]

On 7/27/13 11:56 AM, Lennart Poettering wrote:
> On Fri, 26.07.13 22:13, Miloslav Trmač (mitr at volny.cz) wrote:
> 
>> Hello all,
>> with thin provisioning available, the total and free space values
>> reported by a filesystem do not necessarily mean that that much space
>> is _actually_ available (the actual backing storage may be smaller, or
>> shared with other filesystems).
>>
>> If your package reports disk space usage to users, and bases this on
>> filesystem free space, please consider whether it might need to take
>> LVM thin provisioning into account.
>>
>> The same applies if your package automatically allocates a certain
>> proportion of the total or available space.
>>
>> A quick way to check whether your package is likely to be affected, is
>> to look for statfs() or statvfs() calls in C, or the equivalent in
>> your higher-level library / programming language.
> 
> 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...)

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.

(And if journald sees "100T free" and decides it can use 50T of that,
it's doing it wrong, too) ;)

The truth is somewhere in the middle, but quibbling over whether this
app or that can claim a bit of space behind a thin-provisioned volume
probably isn't useful.

The admin definitely needs tools to see the state of thinly provisioned
storage, but that's the admin's job to worry about, not the app's, IMHO.

-Eric