From: Gionatan Danti <g.danti@assyoma.it>
To: LVM general discussion and development <linux-lvm@redhat.com>
Cc: Demi Marie Obenour <demi@invisiblethingslab.com>
Subject: Re: [linux-lvm] Why is the performance of my lvmthin snapshot so poor
Date: Thu, 16 Jun 2022 21:50:52 +0200 [thread overview]
Message-ID: <171cb55d2d18b73cbbd3d264877a39d6@assyoma.it> (raw)
In-Reply-To: <YqtYDgld/PAOLhpr@itl-email>
Il 2022-06-16 18:19 Demi Marie Obenour ha scritto:
> Also heavy fragmentation can make journal replay very slow, to the
> point
> of taking days on spinning hard drives. Dave Chinner explains this
> here:
> https://lore.kernel.org/linux-xfs/20220509230918.GP1098723@dread.disaster.area/.
Thanks, the linked thread was very interesting.
> Also poor out-of-space handling and unbounded worst-case latency.
Very true.
> Is this still a problem on NVMe storage? HDDs will not really be fast
> no matter what one does, at least unless there is a write-back cache
> that can convert random I/O to sequential I/O. Even that only helps
> much if your working set fits in cache, or if your workload is
> write-mostly.
One of the key features of ZFS is to transform random writes into
sequential ones. With the right recordsize, and coupled with prefetch,
compressed ARC and L2ARC, even HDD pool can be surprisingly usable.
For NVMe pools you should use a much lower recordsize to avoid
read/write amplification, but not lower than 16K to not impair
compression efficiency (unless you are storing mostly uncompressible
stuff). That said, for pure NVMe storage (no compression or other data
transformations) I think XFS, possibly with direct IO, is the fastest
choice by a factor of 2x.
> It does not exist yet. Joe Thornber would be the person to ask
> regarding any plans to create it.
Ok - I was hoping to miss something, but it is not the case.
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
_______________________________________________
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/
prev parent reply other threads:[~2022-06-16 19:51 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-13 8:49 [linux-lvm] Why is the performance of my lvmthin snapshot so poor Zhiyong Ye
2022-06-14 7:04 ` Gionatan Danti
2022-06-14 10:16 ` Zhiyong Ye
2022-06-14 12:56 ` Gionatan Danti
2022-06-14 13:29 ` Zhiyong Ye
2022-06-14 14:54 ` Gionatan Danti
2022-06-15 7:42 ` Zhiyong Ye
2022-06-15 9:34 ` Gionatan Danti
2022-06-15 9:46 ` Zhiyong Ye
2022-06-15 12:40 ` Gionatan Danti
2022-06-15 16:39 ` Demi Marie Obenour
2022-06-16 7:53 ` Demi Marie Obenour
2022-06-16 13:22 ` Gionatan Danti
2022-06-16 16:19 ` Demi Marie Obenour
2022-06-16 19:50 ` Gionatan Danti [this message]
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=171cb55d2d18b73cbbd3d264877a39d6@assyoma.it \
--to=g.danti@assyoma.it \
--cc=demi@invisiblethingslab.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 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 read-only IMAP folder(s) and NNTP newsgroup(s).