From: Frank van der Linden <fllinden@amazon.com>
To: <linux-nfs@vger.kernel.org>, <anna.schumaker@netapp.com>,
<trond.myklebust@hammerspace.com>, <dhowells@redhat.com>
Subject: Re: [PATCH] nfs: round down reported block numbers in statfs
Date: Thu, 10 Sep 2020 20:31:23 +0000 [thread overview]
Message-ID: <20200910203123.GA8274@dev-dsk-fllinden-2c-c1893d73.us-west-2.amazon.com> (raw)
In-Reply-To: <20200910200644.8165-1-fllinden@amazon.com>
On Thu, Sep 10, 2020 at 08:06:44PM +0000, Frank van der Linden wrote:
> nfs_statfs rounds up the numbers of blocks as computed
> from the numbers the server return values.
>
> This works out well if the client block size, which is
> the same as wrsize, is smaller than or equal to the actual
> filesystem block size on the server.
>
> But, for NFS4, the size is usually larger (1M), meaning
> that statfs reports more free space than actually is
> available. This confuses, for example, fstest generic/103.
>
> Given a choice between reporting too much or too little
> space, the latter is the safer option, so don't round
> up the number of blocks. This also simplifies the code.
>
> Signed-off-by: Frank van der Linden <fllinden@amazon.com>
I doubted whether I should send this in as an RFC, since this
is one of those things that might generate more discussion.
In any case, let me add some details here:
generic/103 is a test that sees if adding an xattr to a full
filesystem correctly returns ENOSPC. To achieve that, it gets
the number of free blocks (f_bavail), uses fallocate to allocate that
space minus some slack (512k), and then fills it up with 64k-sized
xattrs.
For NFS (4.2) this fails, because the filesystem rounds the free
blocks up to f_bsize (1M). So even f_bavail minus 512k can
be more than is actually available. The fallocate fails, and
the test fails before it gets to the xattr part.
Other client implementations simply use the lowest common
denominator for f_bsize (512), so the space reporting always
works out. But since wrsize is used here, you have to make
a choice between rounding up or rounding down, and the latter
seems safer.
Sure, all the caveats apply: the stats are just a snapshot, applications
shouldn't rely on the exact data, etc, but I think the xfstest
in question is a decent example of why rounding down is a bit better.
It also simplifies the code.
- Frank
next prev parent reply other threads:[~2020-09-10 20:36 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-10 20:06 [PATCH] nfs: round down reported block numbers in statfs Frank van der Linden
2020-09-10 20:31 ` Frank van der Linden [this message]
2020-09-11 4:32 ` kernel test robot
2020-09-11 4:32 ` kernel test robot
2020-09-11 4:36 ` kernel test robot
2020-09-11 4:36 ` kernel test robot
2020-09-11 21:59 ` Frank van der Linden
2020-09-16 15:14 ` Trond Myklebust
2020-09-16 16:35 ` Frank van der Linden
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=20200910203123.GA8274@dev-dsk-fllinden-2c-c1893d73.us-west-2.amazon.com \
--to=fllinden@amazon.com \
--cc=anna.schumaker@netapp.com \
--cc=dhowells@redhat.com \
--cc=linux-nfs@vger.kernel.org \
--cc=trond.myklebust@hammerspace.com \
/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.