On Sat, Jul 27, 2013 at 6:56 PM, Lennart Poettering
<mzerqung@xxxxxxxxxxx> wrote:
> On Fri, 26.07.13 22:13, Miloslav Trmač (mitr@xxxxxxxx) 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.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
