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@xxxxxxxxxx - info@xxxxxxxxxx > GPG public key ID: FF5F32A8
