* [linux-lvm] Does LVM have any plan/schedule to support btrfs in fsadm @ 2021-06-25 5:28 heming.zhao 2021-06-25 10:57 ` Zdenek Kabelac 0 siblings, 1 reply; 7+ messages in thread From: heming.zhao @ 2021-06-25 5:28 UTC (permalink / raw) To: LVM general discussion and development, Zdenek Kabelac, David Teigland Hello Zdenek & David, From URL: https://fedoraproject.org/wiki/Btrfs The btrfs becomes default filesystem for desktops. Do we have any plan to add btrfs code for scripts/fsadm.sh? If the answer is yes. I could share a suse special patch, this patch had been run about 4 years in suse products. Thanks, Heming _______________________________________________ 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/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [linux-lvm] Does LVM have any plan/schedule to support btrfs in fsadm 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 0 siblings, 1 reply; 7+ messages in thread From: Zdenek Kabelac @ 2021-06-25 10:57 UTC (permalink / raw) To: heming.zhao, LVM general discussion and development, David Teigland Dne 25. 06. 21 v 7:28 heming.zhao@suse.com napsal(a): > Hello Zdenek & David, > > From URL: https://fedoraproject.org/wiki/Btrfs > The btrfs becomes default filesystem for desktops. > > Do we have any plan to add btrfs code for scripts/fsadm.sh? > > If the answer is yes. I could share a suse special patch, this patch > had been run about 4 years in suse products. Hi If you have some patches provided with some good usable testing (lvm2 test suite) - it could be possibly merged. On the other hand helping/suggesting users to use Btrfs on top of lvm2 has also its logical 'question' marks. Since btrfs users should probably be avoiding placing 'another' layer between real hw - when btrfs should be mostly capable handling lvm2 features in its 'very own' way. Each layer has it's own measurable costs. And yeah we do not want to be involved into btrfs related recovery cases, as we simply never understood its handling of attached disks. Regards Zdenek _______________________________________________ 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/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [linux-lvm] Does LVM have any plan/schedule to support btrfs in fsadm 2021-06-25 10:57 ` Zdenek Kabelac @ 2021-06-27 17:40 ` heming.zhao 2021-06-28 3:28 ` Stuart D Gathman 0 siblings, 1 reply; 7+ messages in thread From: heming.zhao @ 2021-06-27 17:40 UTC (permalink / raw) To: Zdenek Kabelac, LVM general discussion and development, David Teigland, Zhong Lidong On 6/25/21 6:57 PM, Zdenek Kabelac wrote: > Dne 25. 06. 21 v 7:28 heming.zhao@suse.com napsal(a): >> Hello Zdenek & David, >> >> From URL: https://fedoraproject.org/wiki/Btrfs >> The btrfs becomes default filesystem for desktops. >> >> Do we have any plan to add btrfs code for scripts/fsadm.sh? >> >> If the answer is yes. I could share a suse special patch, this patch >> had been run about 4 years in suse products. > > > Hi > > If you have some patches provided with some good usable testing (lvm2 test suite) - it could be possibly merged. Patch for fsadm is already many years ago, but test suite is empty. I plan to add some test cases then file the patch files. > > On the other hand helping/suggesting users to use Btrfs on top of lvm2 has also its logical 'question' marks. Since btrfs users should probably be avoiding placing 'another' layer between real hw - when btrfs should be mostly capable handling lvm2 features in its 'very own' way. Each layer has it's own measurable costs. And yeah we do not want to be involved into btrfs related recovery cases, as we simply never understood its handling of attached disks. > In my opinion, the using style of btrfs by many users are same as ext4/xfs. btrfs has lots of features, but there are MAY experimental or not stable. Users prefer to use btrfs core functionality. And not to speak of compatible reasons, in many scenarios, btrfs still works with lvm or mdadm. For minimal code design (minimal bug occur), in fsadm, we only treat btrfs as another ext4/xfs style filesystem. "fsadm resize" executes "btrfs resize" "fsadm check" executes "btrfs scrub" Thanks, Heming _______________________________________________ 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/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [linux-lvm] Does LVM have any plan/schedule to support btrfs in fsadm 2021-06-27 17:40 ` heming.zhao @ 2021-06-28 3:28 ` Stuart D Gathman 2021-06-28 7:29 ` Gionatan Danti 0 siblings, 1 reply; 7+ messages in thread From: Stuart D Gathman @ 2021-06-28 3:28 UTC (permalink / raw) To: LVM general discussion and development Cc: Zhong Lidong, David Teigland, Zdenek Kabelac On Mon, 28 Jun 2021, heming.zhao@suse.com wrote: > In my opinion, the using style of btrfs by many users are same as ext4/xfs. Yes. I like the checksums in metadata feature for enhanced integrity checking. It seems too complicated to have anytime soon - but when a filesystem detects corruption, and is on an LVM (or md) RAID1 layer, an ioctl to read alternate mirror branches to see which (if any) has the correct data would allow recovery. Btrfs does this if it is doing the mirroring, but then you lose all the other features from LVM or md raid10, including running other filesystems and efficient virtual disks for virtual machines. We eventually got DISCARD operations to pass to lower layers. Dealing with mirror branches should really be a thing too. _______________________________________________ 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/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [linux-lvm] Does LVM have any plan/schedule to support btrfs in fsadm 2021-06-28 3:28 ` Stuart D Gathman @ 2021-06-28 7:29 ` Gionatan Danti 2021-06-28 23:00 ` Chris Murphy 0 siblings, 1 reply; 7+ messages in thread From: Gionatan Danti @ 2021-06-28 7:29 UTC (permalink / raw) To: LVM general discussion and development Cc: Stuart, Zhong Lidong, David Teigland, Zdenek Kabelac 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? > It seems too complicated to have anytime soon - but when a filesystem > detects corruption, and is on an LVM (or md) RAID1 layer, an ioctl to > read alternate mirror branches to see which (if any) has the correct > data would allow recovery. Btrfs does this if it is doing the > mirroring, but then you lose all the other features from LVM or md > raid10, including running other filesystems and efficient virtual > disks for > virtual machines. For this to work, LVM should be able to identify the corrupted data. Without checksum, how can you do that? The solution is to use dm-integrity under the RAID layer. It works pretty well, letting apart the big performance drop in the default (journaled) configuration (bitmap is faster, but leave a small window for corruption to happen undetected). 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). > We eventually got DISCARD operations to pass to lower layers. > Dealing with mirror branches should really be a thing too. As said above, the issue is not to read from the mirror leg separately; rather, to detect *which* mirror leg contains valid data. Regards. -- 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/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [linux-lvm] Does LVM have any plan/schedule to support btrfs in fsadm 2021-06-28 7:29 ` Gionatan Danti @ 2021-06-28 23:00 ` Chris Murphy 2021-06-29 22:32 ` Gionatan Danti 0 siblings, 1 reply; 7+ messages in thread From: Chris Murphy @ 2021-06-28 23:00 UTC (permalink / raw) To: LVM general discussion and development; +Cc: Zhong Lidong 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/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [linux-lvm] Does LVM have any plan/schedule to support btrfs in fsadm 2021-06-28 23:00 ` Chris Murphy @ 2021-06-29 22:32 ` Gionatan Danti 0 siblings, 0 replies; 7+ messages in thread From: Gionatan Danti @ 2021-06-29 22:32 UTC (permalink / raw) To: LVM general discussion and development; +Cc: Zhong Lidong, Chris Murphy Il 2021-06-29 01:00 Chris Murphy ha scritto: > Pretty sure it's fixed since 4.14. > https://lkml.org/lkml/2019/2/10/23 Hi Chris, the headline states "harden against duplicate fsid". Does it means that the issue is "only" less likely or it was really solved? > 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. I think the main issue stems for btrfs striking to have 4K CoW extents. ZFS has a default 128K recordsize that, while commanding a fair read/modify/write overhead, works much better with HDDs (for SSDs one can lower recordize to 16K or 32K). XFS with reflink does something similar, doing CoW at 128K block granularity (we had a similar discussion in the past: https://www.spinics.net/lists/linux-xfs/msg35679.html) > 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. If I remember correctly thin LVM minimum chunk size should be 64K, making it much less prone to fragmentation. Moreover, it only CoW when a snapshot if overwritten for the first time (ZFS reallocates at each write and I think btrfs does something similar). In a distant past, I benchmarked a virtual machine running on btrfs over a fallocated+nocow files and the result was quite bleak. Maybe things have improved more than I can imagine... time for some more benchmark I suppose! Do you have any to share? > 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. Yeah, both PostgreSQL and MySQL tend to be slow on btrfs. Regards. -- 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/ ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-06-29 22:32 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 2021-06-29 22:32 ` Gionatan Danti
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).