On Jul 29, 2013, at 3:06 PM, Lennart Poettering <mzerqung(a)0pointer.de> wrote:
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...
e.g. A VM has a 1TB virtual device backed by a qcow2 file residing on a file system with
100GB free space, on a hard drive. That's > 1000%.
It's not just thinp, this has been going on for a long time. So if journald wants to
know something more real in the case of thinp, why not a passthrough from real file system
to virtual file system in the case of qcow2?
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.
Effectively it seems for a long time now there hasn't been an API exposing the
information you think user space requires. Apps using stat are asking a question of an API
that by design only knows about the most immediate file system, not anything beyond which
may be backing it. The request for free space in the immediate file system seems vaguely
reasonable, but needing information beyond the file system seems specious.
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…
It may be that admins are going to need better tools to assist them in monitoring before
crisis events occur. But it does seem the admin shouldn't be creating 16TB qcow2 files
on 1TB real backing, any more than they should do the same with thinp. They're just
asking for trouble, the lie is too big.
Chris Murphy