On 7/27/13 11:56 AM, Lennart Poettering wrote:
On Fri, 26.07.13 22:13, Miloslav Trmač (mitr(a)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