Re: XFS reflink vs ThinLVM

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

On Wed, Jan 15, 2020 at 12:37:52PM +0100, Gionatan Danti wrote:
> On 14/01/20 09:45, Gionatan Danti wrote:
> > On 13/01/20 19:09, Darrick J. Wong wrote:
> > > xfs_io -c 'bmap -c -e -l -p -v <whatever>' test.img
> > 
> > Ok, good to know. Thanks.
> 
> Hi all, I have an additional question about extszinherit/extsize.
> 
> If I understand it correctly, by default it is 0: any non-EOF writes on a
> sparse file will allocate how much space it needs. If these writes are
> random and small enough (ie: 4k random writes), a subsequent sequential read
> of the same file will have much lower performance (because sequential IO are
> transformed in random accesses by the logical/physical block remapping).
> 
> Setting a 128K extszinherit (for the entire filesystem) or extsize (for a
> file/dir) will markedly improve the situation, as much bigger contiguous LBA
> regions can be read for each IO (note: I know SSD and NVME disks are much
> less impacted by fragmentation, but I am mainly speaking about HDD here).
> 
> So, my question: there is anything wrong and/or I should be aware when using
> a 128K extsize, so setting it the same as cowextsize? The only possible
> drawback I can think is a coarse granularity when allocating from the sparse
> file (ie: a 4k write will allocate the full 128k extent).
> 
> Am I missing something?

extszinherit > 0 disables delayed allocation, which means that (in your
case above) if you wrote 1G to a file (using the pagecache) you'd get
8192x 128K calls to the allocator instead of making a single 1G
allocation during writeback.  If you have a lot of memory (or a high vmm
dirty ratio) then you want delalloc over extsize.  Most of the time you
want delalloc, frankly.

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