linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Carlos Maiolino <cmaiolino@redhat.com>
To: Gionatan Danti <g.danti@assyoma.it>
Cc: linux-xfs@vger.kernel.org
Subject: Re: XFS reflink vs ThinLVM
Date: Mon, 13 Jan 2020 12:10:25 +0100	[thread overview]
Message-ID: <20200113111025.liaargk3sf4wbngr@orion> (raw)
In-Reply-To: <fe697fb6-cef6-2e06-de77-3530700852da@assyoma.it>

Hi Gionatan.

On Mon, Jan 13, 2020 at 11:22:51AM +0100, Gionatan Danti wrote:
> Hi all,
> as RHEL/CentOS 8 finally ships with XFS reflink enabled, I was thinking on
> how to put that very useful feature to good use. Doing that, I noticed how
> there is a significant overlap between XFS CoW (via reflink) and dm-thin CoW
> (via LVM thin volumes).
> 
> I am fully aware that they are far from identical, both in use and scope:
> ThinLVM is used to create multiple volumes from a single pool, with
> volume-level atomic snapshot; on the other hand, XFS CoW works inside a
> single volume and with file-level atomic snapshot.
> 
> Still, in at least one use case they are quite similar: single-volume
> storage of virtual machine files, with vdisk-level snapshot. So lets say I
> have a single big volume for storing virtual disk image file, and using XFS
> reflink to take atomic, per file snapshot via a simple "cp --reflink
> vdisk.img vdisk_snap.img".
> 
> How do you feel about using reflink for such a purpose? Is the right tool
> for the job? Or do you think a "classic" approach with dmthin and lvm
> snapshot should be preferred? On top of my head, I can thin about the
> following pros and cons when using reflink vs thin lvm:
> 

> PRO:
> - xfs reflink works at 4k granularity;
> - significantly simpler setup and fs expansion, especially when staked
> devices (ie: vdo) are employed.
> 
> CONS:
> - xfs reflink works at 4k granularity, leading to added fragmentation
> (albeit mitigated by speculative preallocation?);
> - no filesystem-wide atomic snapshot (ie: various vdisk files are reflinked
> one-by-one, at small but different times).
> 
> Side note: I am aware of the fact that a snapshot taken without guest
> quiescing is akin to a crashed guest, but lets ignore that for the moment.
> 

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.


Cheers

-- 
Carlos


  reply	other threads:[~2020-01-13 11:10 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 [this message]
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
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=20200113111025.liaargk3sf4wbngr@orion \
    --to=cmaiolino@redhat.com \
    --cc=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).