[lkml]   [2009]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [LTP] statvfs -> f_bavail
    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?

    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.

     \ /
      Last update: 2009-04-21 02:27    [W:0.020 / U:1.352 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site