On Sat, Jul 27, 2013 at 6:56 PM, Lennart Poettering
<mzerqung(a)0pointer.de> wrote:
On Fri, 26.07.13 22:13, Miloslav Trmač (mitr(a)volny.cz) wrote:
> 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.
Well, we have two subsystems making quite reasonable assumptions, with
the composition being unreasonable. We'll just have to figure a
solution out. That's what distributions are for, after all.
Mirek.
P.S. WRT stat{v,}fs API breakage:
I've been (as can be expected) thinking about this a lot, and the
primary criteria for API breakage are IMHO:
1) When an "old" application is used in an "old" environment, the
results should not change (so that "things keep working", especially
on system upgrades; OTOH it's OK for an old application not to be able
to handle a "new" environment/to be broken by it).
2) When faced with an environment change, an interface should usually
behave strictly as documented, not to preserve a specific use case and
break other use cases (because we can't know how various use cases are
prevalent, especially in binary-only applications).
3) This implies that introducing new features typically means new
adding new interfaces and updating applications to be able to use
them. That's, I think, quite reasonable.
So, I think that stat{v,}fs should continue to only report about the
file system:
1) the value of "free space" reported by stat{v,}fs() for a
SAN-located FS shouldn't change if Fedora 21 suddenly learns about SAN
thin provisioning
2) stat{v,}fs is explicitly documented to report about the file
system, not about the storage stack.
To be clear, it's more important to have _a_ solution than to have
specifically a solution that follows these ideas. That's why it's a
P.S.