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 12:25:26 +0100 [thread overview]
Message-ID: <703a6c17-cc02-2c2c-31ce-6cd12a888743@assyoma.it> (raw)
In-Reply-To: <20200113111025.liaargk3sf4wbngr@orion>
On 13/01/20 12:10, Carlos Maiolino wrote:
> First of all, I think there is no 'right' answer, but instead, use what best fit
> you and your environment. As you mentioned, there are PROs and CONS for each
> different solution.
>
> I use XFS reflink to CoW my Virtual Machines I use for testing. As I know many
> others do the same, and it works very well, but as you said. It is file-based
> disk images, opposed to volume-based disk images, used by DM and LVM.man.
>
> About your concern regarding fragmentation... The granularity is not really 4k,
> as it really depends on the extent sizes. Well, yes, the fundamental granularity
> is block size, but we basically never allocate a single block...
>
> Also, you can control it by using extent size hints, which will help reduce the
> fragmentation you are concerned about.
> Check 'extsize' and 'cowextsize' arguments for mkfs.xfs and xfs_io.
Hi Carlos, thank you for pointing me to the "cowextsize" option. From
what I can read, it default to 32 blocks x 4 KB = 128 KB, which is a
very reasonable granularity for CoW space/fragmentation tradeoff.
On the other hand, "extsize" seems to apply only to realtime filesystem
section (which I don't plan to use), right?
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
next prev parent reply other threads:[~2020-01-13 11:25 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 [this message]
2020-01-13 11:43 ` Carlos Maiolino
2020-01-13 12:21 ` Gionatan Danti
2020-01-13 15:34 ` Gionatan Danti
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=703a6c17-cc02-2c2c-31ce-6cd12a888743@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;
as well as URLs for NNTP newsgroup(s).