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