Re: XFS reflink vs ThinLVM

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

On Mon, Jan 13, 2020 at 04:34:50PM +0100, Gionatan Danti wrote:
> On 13/01/20 13:21, Gionatan Danti wrote:
> > On 13/01/20 12:43, Carlos Maiolino wrote:
> > > I should have mentioned it, my apologies.
> > > 
> > > 'extsize' argument for mkfs.xfs will set the size of the blocks in the RT
> > > section.

mkfs.xfs -d extszinherit=NNN is what you want here.

> > > 
> > > Although, the 'extsize' command in xfs_io, will set the extent size
> > > hints on any
> > > file of any xfs filesystem (or filesystem supporting FS_IOC_FSSETXATTR).
> > > 
> > > Notice you can use xfs_io extsize to set the extent size hint to a
> > > directory,
> > > and all files under the directory will inherit the same extent hint.
> > 
> > My bad, I forgot about xfs_io.
> > Thanks for the detailed explanation.
> 
> Well, I did some test with a reflinked file and I must say I am impressed on
> how well XFS handles small rewrites (for example 4K).
> 
> From my understanding, by mapping at 4K granularity but allocating at 128K,
> it avoid most read/write amplification *and* keep low fragmentation. After
> "speculative_cow_prealloc_lifetime" it reclaim the allocated but unused
> space, bringing back any available free space to the filesystem. Is this
> understanding correct?

Right.

> I have a question: how can I see the allocated-but-unused cow extents? For
> example, giving the following files:
> 
> [root@neutron xfs]# stat test.img copy.img
>   File: test.img
>   Size: 1073741824      Blocks: 2097400    IO Block: 4096   regular file
> Device: 810h/2064d      Inode: 131         Links: 1
> Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
> Context: unconfined_u:object_r:unlabeled_t:s0
> Access: 2020-01-13 15:40:50.280711297 +0100
> Modify: 2020-01-13 16:21:55.564726283 +0100
> Change: 2020-01-13 16:21:55.564726283 +0100
>  Birth: -
> 
>   File: copy.img
>   Size: 1073741824      Blocks: 2097152    IO Block: 4096   regular file
> Device: 810h/2064d      Inode: 132         Links: 1
> Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
> Context: unconfined_u:object_r:unlabeled_t:s0
> Access: 2020-01-13 15:40:50.280711297 +0100
> Modify: 2020-01-13 15:40:57.828552412 +0100
> Change: 2020-01-13 15:41:48.190492279 +0100
>  Birth: -
> 
> I can clearly see that test.img has an additional 124K allocated after a 4K
> rewrite. This matches my expectation: a 4K rewrite really allocates a 128K
> blocks, leading to 124K of temporarily "wasted" space.
> 
> But both "filefrag -v" and "xfs_bmap -vep" show only the used space as seen
> by an userspace application (ie: 262144 blocks of 4096 bytes = 1073741824
> bytes).

xfs_bmap -c, but only if you have xfs debugging enabled.

> How can I check the total allocated space as reported by stat?
> Thanks.

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.

--D

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