On 07/29/2013 04:35 PM, Lennart Poettering wrote:
On Mon, 29.07.13 13:48, Eric Sandeen (sandeen@xxxxxxxxxx) 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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
