From: Nate Straz <nate-ltp@refried.org>
To: Michal Simek <michal.simek@petalogix.com>
Cc: Al Viro <viro@ZenIV.linux.org.uk>,
subrata@linux.vnet.ibm.com, ltp-list@lists.sourceforge.net,
John Williams <john.williams@petalogix.com>,
Linux Kernel list <linux-kernel@vger.kernel.org>,
linux-fsdevel@vger.kernel.org
Subject: Re: [LTP] statvfs -> f_bavail
Date: Mon, 20 Apr 2009 18:59:42 -0400 [thread overview]
Message-ID: <20090420225942.GB3590@refried.org> (raw)
In-Reply-To: <49EC1945.1000805@petalogix.com>
On Apr 20 08:42, Michal Simek wrote:
> Al Viro wrote:
> > On Mon, Apr 20, 2009 at 08:16:50AM +0200, Michal Simek wrote:
> >> Hi guys from linux-fsdevel: Can you told us what is the right solution
> >> for my problem above?
> >
> > "Fields that are undefined for a particular file system are set to 0".
> > So what kind of fs are you running that on and is that sucker really
> > defined for it? Note that if it's ramfs or tmpfs with -o nr_blocks=0,
> > there is no such thing as "amount of free space", reserved for root
> > or not.
> I use ramfs and nfs without any -o nr_block=0 option.
> 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?
Sounds like the patch is the right thing to do based on Al's quote. I
would suggest modifying the patch to use fsblkcnt_t as f_bavail is
defined in statvfs(2). Other than that, the patch looks good.
Nate
WARNING: multiple messages have this Message-ID (diff)
From: Nate Straz <nate-ltp-q5Rx+M6Tjo1AfugRpC6u6w@public.gmane.org>
To: Michal Simek <michal.simek-g5w7nrANp4BDPfheJLI6IQ@public.gmane.org>
Cc: ltp-list-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
Linux Kernel list
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Al Viro <viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
John Williams
<john.williams-g5w7nrANp4BDPfheJLI6IQ@public.gmane.org>
Subject: Re: statvfs -> f_bavail
Date: Mon, 20 Apr 2009 18:59:42 -0400 [thread overview]
Message-ID: <20090420225942.GB3590@refried.org> (raw)
In-Reply-To: <49EC1945.1000805-g5w7nrANp4BDPfheJLI6IQ@public.gmane.org>
On Apr 20 08:42, Michal Simek wrote:
> Al Viro wrote:
> > On Mon, Apr 20, 2009 at 08:16:50AM +0200, Michal Simek wrote:
> >> Hi guys from linux-fsdevel: Can you told us what is the right solution
> >> for my problem above?
> >
> > "Fields that are undefined for a particular file system are set to 0".
> > So what kind of fs are you running that on and is that sucker really
> > defined for it? Note that if it's ramfs or tmpfs with -o nr_blocks=0,
> > there is no such thing as "amount of free space", reserved for root
> > or not.
> I use ramfs and nfs without any -o nr_block=0 option.
> 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?
Sounds like the patch is the right thing to do based on Al's quote. I
would suggest modifying the patch to use fsblkcnt_t as f_bavail is
defined in statvfs(2). Other than that, the patch looks good.
Nate
------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
next prev parent reply other threads:[~2009-04-20 23:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <49E759FB.70103@petalogix.com>
[not found] ` <49E847FB.1030801@petalogix.com>
[not found] ` <20090417173107.GA3590@refried.org>
2009-04-20 6:16 ` [LTP] statvfs -> f_bavail Michal Simek
2009-04-20 6:26 ` Al Viro
2009-04-20 6:42 ` Michal Simek
2009-04-20 22:59 ` Nate Straz [this message]
2009-04-20 22:59 ` Nate Straz
2009-04-21 0:25 ` [LTP] " Al Viro
2009-04-21 0:38 ` Andreas Dilger
2009-04-21 0:47 ` Al Viro
2009-04-21 8:45 ` Michal Simek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090420225942.GB3590@refried.org \
--to=nate-ltp@refried.org \
--cc=john.williams@petalogix.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ltp-list@lists.sourceforge.net \
--cc=michal.simek@petalogix.com \
--cc=subrata@linux.vnet.ibm.com \
--cc=viro@ZenIV.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.