On 07/29/2013 03:05 PM, Steve Grubb wrote:
On Friday, July 26, 2013 09:29:41 PM Eric Sandeen wrote:
On 7/26/13 3:13 PM, Miloslav Trmač wrote:
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.
statfs will still tell you how much space the filesystem has allocated,
as well as how much space it thinks it has left, based on the total
space the disk has *said* it has available, just like it always ever
did.
The difference, of course, is that you might actually run out of blocks
before you fill the fs. But I can't think offhand what apps would care.
And again, it's something the admin shouldn't let happen.
The audit system also cares about space available. We tell people to create a
partition specifically for auditing so that we can keep close track on what's
left. But we have the requirement that for people that depend on it to "take
away" system access should the ability to record audit events fail. We also
need an accurate estimation before we run out so we can send an admin defined
warning when the disk has filled to a certain point so that they can archive
files or make space available.
If we run out of disk space and were not able to warn admins and this was a
shop that really cares about auditing, the system will either be shutdown or
sent to single user mode for corrective action. So, having accurate space left
numbers is real important so that systems don't get shutdown unexpectedly.
-Steve
Of course, if you simply can never run out of space and have a special file
system/device of your own, you should use fully provisioned storage.
dm-thin is not about solving *every* problem :)
ric
For now, consider it completely transparent to the user (unless the
admin doesn't keep up, in which case it will be anything *but*
transparent).
TBH, when the backing store runs out of space, things do get pretty
ugly at this point. It's work that needs to be done to make it more
robust & graceful.
-Eric
Mirek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
