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@xxxxxxxxxx> 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
