All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Murphy <lists@colorremedies.com>
To: LVM general discussion and development <linux-lvm@redhat.com>
Cc: Zhong Lidong <lidong.zhong@suse.com>
Subject: Re: [linux-lvm] Does LVM have any plan/schedule to support btrfs in fsadm
Date: Mon, 28 Jun 2021 17:00:18 -0600	[thread overview]
Message-ID: <CAJCQCtQLTPqdcsG0b9gckteBu8_7vkbAta=tD5f8EjO=NCdyWw@mail.gmail.com> (raw)
In-Reply-To: <35d4978f0aa1c0a78c8c618557ba15e5@assyoma.it>

On Mon, Jun 28, 2021 at 1:33 AM Gionatan Danti <g.danti@assyoma.it> wrote:
>
> Il 2021-06-28 05:28 Stuart D Gathman ha scritto:
> > Yes.  I like the checksums in metadata feature for enhanced integrity
> > checking.
>
> Until recently btrfs has issue when a LVM snapshot was mounted. It is
> now solved?

Pretty sure it's fixed since 4.14.
https://lkml.org/lkml/2019/2/10/23


> That said, for rewrite-heavy workload (virtual machines, databases, etc)
> btrfs is very slow (and disabling CoW is not a solution for me, as it
> also disables checksum, compression, etc).

It's not inherently slow, it's a tracking cost problem as very large
numbers of extents accumulate. And it also depends on the write
pattern of the guest file system. If you use Btrfs in a guest on a
host using Btrfs, it's a lot more competitive. There's certainly room
for improvement, possibly with some hinting to avoid writing out a
metric ton of 4KiB blocks as other file systems are prone to doing,
where btrfs can turn these into  largely sequential writes, they lose
any locality optimization the guest file system expects for subsequent
reads. A lot of the locality issue is a factor on rotational devices.
When talking about hundreds of thousands of extents per VM file, this
has a noticeable impact on even SSDs, but the much reduced latency
makes it tolerable for some scenarios.

But I've seen similar problems with VM's on LVM thinp when making many
snapshots and incurring cow, however temporary (like a btrfs nodatacow
file that's subject to snapshots or reflink copies; or a backing file
on xfs likewise reflink copied). There really isn't much better we can
do than LVM thick in this regard. And if that's the standard bearer,
it's not much different if you fallocate a nodatacow file.

Some databases are cow friendly, notably rocksdb. And sqlite with wal
enabled is at least not cow unfriendly. The worst offender seems to be
postgresql but I haven't seen any benchmarking since the multiple
kernel series of fsync work done on btrfs to improve the performance
of databases in general; that was kernel 5.8 through 5.11.


-- 
Chris Murphy

_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/


  reply	other threads:[~2021-06-29  7:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-25  5:28 [linux-lvm] Does LVM have any plan/schedule to support btrfs in fsadm heming.zhao
2021-06-25 10:57 ` Zdenek Kabelac
2021-06-27 17:40   ` heming.zhao
2021-06-28  3:28     ` Stuart D Gathman
2021-06-28  7:29       ` Gionatan Danti
2021-06-28 23:00         ` Chris Murphy [this message]
2021-06-29 22:32           ` 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='CAJCQCtQLTPqdcsG0b9gckteBu8_7vkbAta=tD5f8EjO=NCdyWw@mail.gmail.com' \
    --to=lists@colorremedies.com \
    --cc=lidong.zhong@suse.com \
    --cc=linux-lvm@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.