Re: XFS reflink vs ThinLVM

["Darrick J. Wong" <darrick.wong@oracle.com>]

On Mon, Jan 13, 2020 at 06:00:15PM +0100, Gionatan Danti wrote:
> On 13/01/20 17:53, Darrick J. Wong wrote:
> > mkfs.xfs -d extszinherit=NNN is what you want here.
> 
> Hi Darrik, thank you, I missed that option.
> 
> > Right.
> 
> Ok
> 
> > xfs_bmap -c, but only if you have xfs debugging enabled.
> 
> [root@neutron xfs]# xfs_bmap -c test.img
> /usr/sbin/xfs_bmap: illegal option -- c
> Usage: xfs_bmap [-adelpvV] [-n nx] file...
> 
> Maybe my xfs_bmap version is too old:

Doh, sorry, thinko on my part.  -c is exposed in the raw xfs_io command
but not in the xfs_bmap wrapper.

xfs_io -c 'bmap -c -e -l -p -v <whatever>' test.img

> > If you happen to have rmap enabled, you can use the xfs_io fsmap command
> > to look for 'cow reservation' blocks, since that 124k is (according to
> > ondisk metadata, anyway) owned by the refcount btree until it gets
> > remapped into the file on writeback.
> 
> I see. By default, on RHEL at least, rmapbt is disabled. As a side note, do
> you suggest enabling it when creating a new fs?

If you are interested in online scrub, then I'd say yes because it's the
secret sauce that gives online metadata checking most of its power.  I
confess, I haven't done a lot of performance analysis of rmap lately,
the metadata ops overhead might still be in the ~10% range.

The two issues preventing rmap from being turned on by default (at least
in my head) are (1) scrub itself is still EXPERIMENTAL and (2) it's not
100% clear that online fsck is such a killer app that everyone will want
it, since you always pay the performance overhead of enabling rmap
regardless of whether you use xfs_scrub.

(If your workload is easily restored from backup/Docker and you need all
the performance you can squeeze then perhaps don't enable this.)

Note that I've been running with rmap=1 and scrub=1 on all systems since
2016, and frankly I've noticed the system stumbling over broken
writeback throttling much more than whatever the tracing tools attribute
to rmap.

--D

> Thanks.
> 
> -- 
> Danti Gionatan
> Supporto Tecnico
> Assyoma S.r.l. - www.assyoma.it
> email: g.danti@assyoma.it - info@assyoma.it
> GPG public key ID: FF5F32A8