Why this article had to be segmented into 10 pages is beyond me, however.
The reason I didn't read the article.
ZFS, BTRFS, XFS, EXT4 and LVM with KVM – A Storage Performance Comparison (2015)
11–20 of 85 posts
Re: ZFS, BTRFS, XFS, EXT4 and LVM with KVM – A Storage Performance Comparison (2015)
#12Earlier quoted context omitted.
Kvm (or any overwrite workload for that matter) is the worst possible workload for btrfs because of COW. We have ideas to address this but honestly it's not high on the list.
What kinds of workloads is it designed for then?
It's a general purpose file system, it does great with metadata heavy workloads and normal streaming writes. The overwrite case is special because of COW. Eventually we'll be comparable to everybody else but we aren't now.
Re: ZFS, BTRFS, XFS, EXT4 and LVM with KVM – A Storage Performance Comparison (2015)
#13What is with BTRFS? It stands out in every single test (and not in a good way).
Kvm (or any overwrite workload for that matter) is the worst possible workload for btrfs because of COW. We have ideas to address this but honestly it's not high on the list.
This is sad since even with some performance loss compression and offline deduplication for VM images sounds like nice feature.
Is there any docs that explain why COW make Btrfs so slow compared to QCOW2?
Re: ZFS, BTRFS, XFS, EXT4 and LVM with KVM – A Storage Performance Comparison (2015)
#14Re: ZFS, BTRFS, XFS, EXT4 and LVM with KVM – A Storage Performance Comparison (2015)
#15Why this article had to be segmented into 10 pages is beyond me, however.
I'm not author, but since I know some Joomla magic this might help:
http://www.ilsistemista.net/index.php/virtualization/47-zfs-...
Re: ZFS, BTRFS, XFS, EXT4 and LVM with KVM – A Storage Performance Comparison (2015)
#16What is with BTRFS? It stands out in every single test (and not in a good way).
Kvm (or any overwrite workload for that matter) is the worst possible workload for btrfs because of COW. We have ideas to address this but honestly it's not high on the list.
But shouldn't NOCOW mitigate that? (which the article does for some tests)
Re: ZFS, BTRFS, XFS, EXT4 and LVM with KVM – A Storage Performance Comparison (2015)
#17Why this article had to be segmented into 10 pages is beyond me, however.
To make matters worse, their web site has run out of MySQL database connections, and currently the site is unavailable.
Re: ZFS, BTRFS, XFS, EXT4 and LVM with KVM – A Storage Performance Comparison (2015)
#18*on Linux. ZFS on Linux in particular is not representative of ZFS on BSD or Solaris.
Not sure what you mean here. They showed that ZFS performed well on linux. Are you saying that ZFS performs poorly on BSD and Solaris? Love me some ZFS and it works well pretty much everywhere. OpenZFS shows good promise of keeping (bringing) the BSD, Illumos and Linux versions in line with each other.
> Are you saying that ZFS performs poorly on BSD and Solaris?
I think LeoPanthera is saying it performs better on BSD (well FreeBSD) and Solaris (well Illumos-based in particular).
Re: ZFS, BTRFS, XFS, EXT4 and LVM with KVM – A Storage Performance Comparison (2015)
#19Re: ZFS, BTRFS, XFS, EXT4 and LVM with KVM – A Storage Performance Comparison (2015)
#20Earlier quoted context omitted.
Kvm (or any overwrite workload for that matter) is the worst possible workload for btrfs because of COW. We have ideas to address this but honestly it's not high on the list.
This is sad since even with some performance loss compression and offline deduplication for VM images sounds like nice feature. Is there any docs that explain why COW make Btrfs so slow compared to QCOW2?
There are no docs. I'm not a qcow2 expert, what I know is very basic so anything I say about qcow2 can be very wrong.
So qcow has a read only base image that gets updated when we change things. The image format just had the changes from the original image. So you update a package, it adds some metadata to point at the new stuff and adds the data in and you are done.
So with btrfs you have this image on top of btrfs, so you update a file and its metadata inside the image. Say you start with a pristine image that's in nice big extents. You update a package which changes small chunks all over the file. Let's say you update 12 4K extents. So now instead of one extent you now have 36 extents. This affects everything, fsyncs take longer because there's more extents we have to write out, the space is more fragmented so cold cache reads are more expensive, the csums are no longer contiguous so they also take up a larger more fragmented area. It has this really terrible cascading effect.