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

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

#81

Post by mrmondo » Mon, May 23, 2016, 5:21 PM UTC

ryao wrote: post #79

mrmondo wrote: post #66

- Very old kernel used (3.10!), makes me wonder how old the packages like btrfs-progs are as well. - BTRFS not mounted with compression (compress=lzo) - Don't use QCOW2, just don't, it's slow and you're just adding extra layers where you don't need to. It would be interesting to see you re-run these tests using a modern kernel, say at least 4.4 and either raw block devices or logical volumes along with mounting BTRFS…

The benchmark configuration appears to be designed to evaluate the use of storage technologies for a KVM host. Consequently, saying to use raw block devices when giving tips for improving btrfs performance is contradictory. Also, there are a large number of people that will not run a newer kernel for several years because they are on RHEL6 or RHEL7, so while newer kernels are interesting, we should not discount the r…

I disagree (politely) with your assumption about QCOW2 and BTRFS performance, if I get some time this week I'll do some objective benchmarking (I design and build Linux based storage systems) and see hey I might be proven wrong but regardless I can let you know the results if you're interested?

People not willing to update their kernel in production environments is a social problem, not a technical problem. The kernel is one of the most reliable, well tested and reviewed software projects in the world. When you upgrade your kernel 99.5% of the time you get new features, performance and bug fixes without any negotiate impact. There are of course rare corner cases especially if running propriety hardware when they are generally slower to release updates that show the benefits of a modern kernel.

The problem there is the culture and traditional slow moving operational engineered haven't all embraced the well proven fact that regular, small charges are safer and have various added benefits.

There is also a serious language barrier between many engineers and management / project managers who clearly would not be likely to understand the benefit of upgrading to a kernel version that say properly supported the new SCSI blk_mq backend for storage, so there either needs to be degree of trust and respect to (proven) engineers(ing) and teams or they need to be clearly taught the value add of a fast release cycle and practising quick (hopefully automated) patching. That's where I think books like Gene Kim's - The Phoenix Project and his soon to be released book - The DevOps Handbook which may in fact be more useful to people performing PM/PO tasks.

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

#82

Post by newman314 » Mon, May 23, 2016, 9:24 PM UTC

tremon wrote: post #67

Zardoz84 wrote: post #62

Interesting. But in our case, we are running Hyper-V VMs (son sadly NTFS on host), were the VMs uses EXT4, and a few uses BTRFS. The only problem that we had, was with a uncontrolled poweroff a year ago. Looks that BRTFS had some trouble recovering from it, but we manage to restore all data from the partitions. However, the flexibility that offer BTRFS (transparent compression, increasing hard disk space on demand, e…

increasing hard disk space on demand Note that ext4 on LVM can do this as well, you just need to plan for it in advance. All of my systems are configured as fs-on-lvm, even the single-disk ones. I've found it's just less hassle: I can do all storage migration or storage expansion without ever taking the machine offline.

This.

I just realized one of my Ubuntu VMs was built without LVM and only found out because I was going to expand storage on it. Luckily, it's just a toy VM on the home server so no biggie. But yes, having fs-on-lvm should just be the default now since it makes expansion so much easier.

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

#83

Post by newman314 » Mon, May 23, 2016, 10:58 PM UTC

Got a Synology NAS showing up today. Based on the results here and the fuzzing link posted several days ago (and elsewhere ITT), it looks like I'll be going with ext4 for now.

Amazingly, I've had a ReadyNAS device last me over 10 years and here's to hoping this one lasts a similar period of time.

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

#84

Post by ryao » Tue, May 24, 2016, 12:15 AM UTC

mrmondo wrote: post #81

ryao wrote: post #79

Earlier quoted context omitted.

The benchmark configuration appears to be designed to evaluate the use of storage technologies for a KVM host. Consequently, saying to use raw block devices when giving tips for improving btrfs performance is contradictory. Also, there are a large number of people that will not run a newer kernel for several years because they are on RHEL6 or RHEL7, so while newer kernels are interesting, we should not discount the r…

I disagree (politely) with your assumption about QCOW2 and BTRFS performance, if I get some time this week I'll do some objective benchmarking (I design and build Linux based storage systems) and see hey I might be proven wrong but regardless I can let you know the results if you're interested? People not willing to update their kernel in production environments is a social problem, not a technical problem. The kerne…

You said "Don't use QCOW2, just don't, it's slow and you're just adding extra layers where you don't need to.". I was agreeing with you when I said that it also has that effect on ZFS. What is my "assumption about QCOW2 and BTRFS performance"?

As for newer kernels, code churn tends to break things that previously worked, which upsets customers who want bugs to decrease as a function of time, rather than go up. Vendors like Redhat will not update distributions like RHEL to newer kernels because of that and they will not support kernels that they do not ship. That is why people run older kernels.

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

#85

Post by mrmondo » Tue, May 24, 2016, 8:31 AM UTC

ryao wrote: post #84

mrmondo wrote: post #81

Earlier quoted context omitted.

I disagree (politely) with your assumption about QCOW2 and BTRFS performance, if I get some time this week I'll do some objective benchmarking (I design and build Linux based storage systems) and see hey I might be proven wrong but regardless I can let you know the results if you're interested? People not willing to update their kernel in production environments is a social problem, not a technical problem. The kerne…

You said "Don't use QCOW2, just don't, it's slow and you're just adding extra layers where you don't need to.". I was agreeing with you when I said that it also has that effect on ZFS. What is my "assumption about QCOW2 and BTRFS performance"? As for newer kernels, code churn tends to break things that previously worked, which upsets customers who want bugs to decrease as a function of time, rather than go up. Vendor…

That's complete fud regarding newer kernels - the linux kernel gets more stable over time, not less - it's like updating your drivers - you don't hold back your graphics card drivers because the new stable release might be less stable than your outdated one that came bundled with your PC.