public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Gionatan Danti <g.danti@assyoma.it>
To: linux-xfs@vger.kernel.org
Cc: "'g.danti@assyoma.it'" <g.danti@assyoma.it>
Subject: Re: XFS reflink vs ThinLVM
Date: Mon, 13 Jan 2020 16:34:50 +0100	[thread overview]
Message-ID: <39b50e2c-cb78-3bcd-0130-defa9c573b71@assyoma.it> (raw)
In-Reply-To: <627cb07f-9433-ddfd-37d7-27efedd89727@assyoma.it>

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

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

How can I check the total allocated space as reported by stat?
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

  reply	other threads:[~2020-01-13 15:34 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-13 10:22 XFS reflink vs ThinLVM Gionatan Danti
2020-01-13 11:10 ` Carlos Maiolino
2020-01-13 11:25   ` Gionatan Danti
2020-01-13 11:43     ` Carlos Maiolino
2020-01-13 12:21       ` Gionatan Danti
2020-01-13 15:34         ` Gionatan Danti [this message]
2020-01-13 16:53           ` Darrick J. Wong
2020-01-13 17:00             ` Gionatan Danti
2020-01-13 18:09               ` Darrick J. Wong
2020-01-14  8:45                 ` Gionatan Danti
2020-01-15 11:37                   ` Gionatan Danti
2020-01-15 16:39                     ` Darrick J. Wong
2020-01-15 17:45                       ` Gionatan Danti
2020-01-17 21:58                         ` Gionatan Danti
2020-01-17 23:42                           ` Darrick J. Wong
2020-01-18 11:08                             ` Gionatan Danti
2020-01-18 23:06                               ` Darrick J. Wong
2020-01-19  8:45                                 ` Gionatan Danti
2020-01-13 16:14 ` Chris Murphy
2020-01-13 16:25   ` Gionatan Danti

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=39b50e2c-cb78-3bcd-0130-defa9c573b71@assyoma.it \
    --to=g.danti@assyoma.it \
    --cc=linux-xfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox