Re: [LTP] statvfs -> f_bavail

[Al Viro]

On Mon, Apr 20, 2009 at 08:42:13AM +0200, Michal Simek wrote:

> That mean that for all other fs is possible to set nr_blocks=0 (f_bavail=0) and for all this cases
> fsync02 test failed. That mean that make sense to test f_bavail value in LTP and if is zero
> don't work with it. Am I right?

Huh?
	a) ramfs has no such thing as "amount of available space", simply
because it has no limit on total size occupied.
	b) tmpfs *does* have a limit and will report f_bavail, unless you
tell it not to limit (that's what nr_blocks=... is; it sets the fs size limit
for tmpfs and 0 means "no limit, act as ramfs").
	c) nfs client has no fscking clue how much space is left on server
for non-root; moreover, in case of nfs root on client might very well be
mapped to something else on server.
	d) something local on-disk (ext2, ext3, etc., etc.) can and will fill
->f_bavail with non-zero data
	e) procfs has nothing to put there, period.  You can't create
files there, it doesn't have anything like fixed-sized something that might
be partially empty.

The bottom line: some filesystems have reasonable answer to "how much space
is left on that fs for non-root user".  Those fill the field in question.
And for some filesystems the question makes no sense whatsoever.

So statfs(2) has every right to leave the damn thing zero.  Whether it
will do that or not depends on the fs type.  Userland code must be able
to cope with that, unless it *knows* which filesystem type will it be
dealing with.

Incidentally, nr_blocks=... will be cheerfully shat upon by just about every
fs out there.  It's tmpfs-specific.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/