> 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", simplybecause it has no limit on total size occupied. b) tmpfs *does* have a limit and will report f_bavail, unless youtell it not to limit (that's what nr_blocks=... is; it sets the fs size limitfor tmpfs and 0 means "no limit, act as ramfs"). c) nfs client has no fscking clue how much space is left on serverfor non-root; moreover, in case of nfs root on client might very well bemapped 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 createfiles there, it doesn't have anything like fixed-sized something that mightbe partially empty.

The bottom line: some filesystems have reasonable answer to "how much spaceis 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 itwill do that or not depends on the fs type. Userland code must be ableto cope with that, unless it *knows* which filesystem type will it bedealing with.

Incidentally, nr_blocks=... will be cheerfully shat upon by just about everyfs out there. It's tmpfs-specific.