Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ZFS, BTRFS, XFS, EXT4 and LVM with KVM – A Storage Performance Comparison (2015)

ilsistemista.net

Post reply on HN
Print view View original

21–30 of 85 posts

Re: ZFS, BTRFS, XFS, EXT4 and LVM with KVM – A Storage Performance Comparison (2015)

#21

Post by josefbacik »

daurnimator wrote: post #16
josefbacik wrote: post #7

Earlier 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.

But shouldn't NOCOW mitigate that? (which the article does for some tests)

NOCOW is horribly expensive because we still have to go check and make sure that there are no snapshots pointing at the changing extents. It only solves the fragmentation issue, and if you don't prealloc your image it doesn't even do that.

Re: ZFS, BTRFS, XFS, EXT4 and LVM with KVM – A Storage Performance Comparison (2015)

#22

Post by loeg »

josefbacik wrote: post #7
matt-attack wrote: post #5

What 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.

Shouldn't ZFS have similar problems with overwrite workloads?

Re: ZFS, BTRFS, XFS, EXT4 and LVM with KVM – A Storage Performance Comparison (2015)

#23

Post by josefbacik »

loeg wrote: post #22
josefbacik wrote: post #7

Earlier 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.

Shouldn't ZFS have similar problems with overwrite workloads?

ZFS has a 7 year head start on BTRFS and has traditionally had about 5 times as many core contributors at any given time so I imagine they've solved this in some novel way by now.

Re: ZFS, BTRFS, XFS, EXT4 and LVM with KVM – A Storage Performance Comparison (2015)

#24

Post by SXX »

josefbacik wrote: post #20
SXX wrote: post #13

Earlier quoted context omitted.

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,…

I tested it with preallocated raw images on Btrfs and that setup was slow as well. If I get you right it's must be possible to somehow allign VM disk sectors to Btrfs sectors for performance boost. Or compression and deduplication usage going to kill performance anyway?

Re: ZFS, BTRFS, XFS, EXT4 and LVM with KVM – A Storage Performance Comparison (2015)

#27

Post by [deleted] »

josefbacik wrote: post #23
loeg wrote: post #22

Earlier quoted context omitted.

Shouldn't ZFS have similar problems with overwrite workloads?

ZFS has a 7 year head start on BTRFS and has traditionally had about 5 times as many core contributors at any given time so I imagine they've solved this in some novel way by now.

[deleted]

Re: ZFS, BTRFS, XFS, EXT4 and LVM with KVM – A Storage Performance Comparison (2015)

#29

Post by tux1968 »

ryao wrote: post #28
ars wrote: post #4

This is more than a year old. I've been told that btrfs has improved greatly in that time.

ZFS has not stood still during that time either.

But it had a lot less low-hanging-fruit to pick during that time.

Re: ZFS, BTRFS, XFS, EXT4 and LVM with KVM – A Storage Performance Comparison (2015)

#30

Post by ryao »

tux1968 wrote: post #29
ryao wrote: post #28

Earlier quoted context omitted.

ZFS has not stood still during that time either.

But it had a lot less low-hanging-fruit to pick during that time.

I could argue otherwise, but that is beside the point on enterprise distributions where these tests were done. The latest ZFS code is always avaliable on those while the btrfs code is stagnant there. The btrfs developers delegate responsibility of backporting their changes to distribution developers, who never do any backports. Consequently, the newer btrfs code is not very relevant as far as benchmarks on RHEL and others are concerned.
Post reply on HN