Re: Why is the performance of my lvmthin snapshot so poor
Gionatan Danti <[email protected]>
| Newsgroups | gmane.linux.lvm.general |
|---|---|
| Message-ID | <[email protected]> |
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/[email protected]/. 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: [email protected] - [email protected] GPG public key ID: FF5F32A8 _______________________________________________ linux-lvm mailing list [email protected] https://listman.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/