Re: How to reliably measure fs usage with reflinks enabled?

[Mike Fleetwood <mike.fleetwood@googlemail.com>]

On 15 May 2018 at 02:29, Dave Chinner <david@fromorbit.com> wrote:
> So the reflink code reserved ~7GB of space in the filesystem (less
> than 1%) for it's own reflink related metadata if it ever needs it.
> It hasn't used it yet but we need to make sure that it's available
> when the filesystem is near ENOSPC. Hence it's considered used space
> because users cannot store user data in that space.
>
> The change I plan to make is to reduce the user reported filesystem
> size rather than account for it as used space. IOWs, you'd see a
> filesystem size of 889G instead of 896G, but have only 8.8GB used.
> It means exactly the same thingi and will behave exactly the same
> way, it's just a different space accounting technique....

I'm one of the authors of GParted and it uses the reported file system
size [1] and compares it to the block device size to see if the file
system fills the partition or not and whether to show unallocated space
to the user and advise them to grown the file system to fill the block
device [2].  As such we prefer that the reported size of the file system
match the highest offset that the file system can write to in the block
device.  Hence space not free for storing data such as super blocks and
other reserved metadata be included in used space.

[1] For mounted file systems it uses statvfs() and unmounted XFS file
    systems it uses:
      xfs_db -c 'sb 0' -c 'print blocksize' -c 'print dblocks' /dev/sda7
    to get the fs block size and number of blocks.

[2] For full disclosure, because tools for various FSs under report
    their file system size, there is a heuristic that there must be at
    least 2% difference before unallocated space and grow file system
    recommendation is generated so under reporting the FS size by less
    than 1% wouldn't actually be an issue. for us.

Just providing an app authors point of view.

Thanks,
Mike