OpenZFS Lands A Very Nice Performance Optimization

[phoronix]

Phoronix: OpenZFS Lands A Very Nice Performance Optimization

A very nice feature pull request was merged to OpenZFS that can provide a nice performance improvement to this open-source ZFS file-system implementation to kick off the new year...

https://www.phoronix.com/news/OpenZFS-Uncached-Prefetch

[Danny3]

Is this the one with the license problems that will never be accepted in the Linux kernel?
When you have EXT4 and BTRFS, I don't understand why would anyone use a file system that doesn't properly support the Linux kernel having a compatible license.

[jrch2k8]

Is this the one with the license problems that will never be accepted in the Linux kernel?
Besides EXT4 and BTRFS, I don't understand why would anyone use a file system that doesn't properly support the Linux kernel having a compatible license.

1.) Is factually way better
2.) Is not really incompatible but more about linux devs being unsure about CDDL compatibility in case of some troll

[skeevy420]

Is this the one with the license problems that will never be accepted in the Linux kernel?
Besides EXT4 and BTRFS, I don't understand why would anyone use a file system that doesn't properly support the Linux kernel having a compatible license.

I know you didn't mean it like that, but the way you that said implies that Ext4 and BTRFS have license issues.

Yes, this is the one.

They use it for the same reason some people pick NVIDIA over AMD -- it's better for their use-cases. I wouldn't pick NVIDIA over AMD, but some people would. I would pick OpenZFS because it allows mixing and matching of settings to a very fine degree that no other file system allows. You can pick OpenZFS because it is one tool where as with built-in you need three tools: LUKS, LVM, and BTRFS. That said, LUKS+OpenZFS is a bit better if you're worried about a local hacker trying to figure out what is on a disk based on metadata. It's still less layers for more features.

Anyhoo, OpenZFS is also crossplatform between Linux, FreeBSD, and Solaris and eventually with macOS and Windows. What are the next best cross platform file systems? NTFS? Vfat?

Just because it's the "wrong" kind of open source doesn't negate that it's open source.

[whitecat]

Besides EXT4 and BTRFS, I don't understand why would anyone use a file system that doesn't properly support the Linux kernel having a compatible license.

Because:
- it's just a "problem" of license. CDDL is OSI approved, it's opensource. And other people integrate easily OpenZFS with Linux for you (TrueNAS, Proxmox, for instance). So if it's not in Linux, whatever...
- there is no competion on Linux against OpenZFS. The best one would be Stratis I guess, which is pretty young (I never tested it)... Ext4 is just a simple filesystem. Btrfs, lol, it can't even handle a simple RAID5 safely...

[Developer12]

Is this the one with the license problems that will never be accepted in the Linux kernel?
Besides EXT4 and BTRFS, I don't understand why would anyone use a file system that doesn't properly support the Linux kernel having a compatible license.

It really doesn't matter. OpenZFS is a free, copyleft software and you can run it on any operating system you want. Linux, BSD, even MacOS and Windows.

Right now it's simply shipped and loaded as a module, which very effectively solves all of the licencing concerns. Ubuntu has been shipping it in their distro for almost a decade (2016) without a single issue.

That, and ZFS is better than BTRFS in almost every way. Not only is the performance good, but it's also FAR more stable.

From the very beginning ZFS has been CI tested through ztest in every possible scenario, which helped the devs find and correct a wide array of edge cases so that users never had to. With BTRFS, if pretty much anything unexpected happens or the disk just so happens to corrupt the wrong bit of metadata, there's still a very good chance the filesystem will eat itself even without RAID5/6. The internet *continues* to see new testimonials posted *monthly* of people loosing data to BRTFS. Meanwhile, during all the time at fishworks exactly *one* customer ever lost data to ZFS, when a Sun support technician decided to edit kernel data structures live. Reports of ZFS failing are few and far between, even despite it's extensive use in enterprise to this day.

ZFS also meets feature parity with BTRFS and more. It supports snapshots, adding vdevs, removing entire vdevs, and so on. It also plays nicer with NFS while having the best filesystem cache of any filesystem on linux, period. (the ARC is far better than the linux page cache, which only knows about LRU) ZFS also features native encryption, while BTRFS still doesn't work with fscrypt properly. The one complaint people have is the inability to add disks to one of your raidz vdevs, a feature which has been implemented and is undergoing testing while waiting for the next major release.

In all honestly, there's really absolutely no reason to use BugFS at all.

[Volta]

That, and ZFS is better than BTRFS in almost every way. Not only is the performance good, but it's also FAR more stable. [...]

ZFS also meets feature parity with BTRFS and more. It supports snapshots, adding vdevs, removing entire vdevs, and so on. It also plays nicer with NFS while having the best filesystem cache of any filesystem on linux, period. (the ARC is far better than the linux page cache, which only knows about LRU) ZFS also features native encryption, while BTRFS still doesn't work with fscrypt properly. The one complaint people have is the inability to add disks to one of your raidz vdevs, a feature which has been implemented and is undergoing testing while waiting for the next major release.

In all honestly, there's really absolutely no reason to use BugFS at all.

Nice fairy tales:

https://storytime.ivysaur.me/posts/why-not-zfs/

[satadru]

Excited for OpenZFS 2.2 to be tagged at some point soon. This, plus the fixes for overlay compatibility so docker containers can work well with zfs will make for a compelling upgrade.

[user1]

Not only is the performance good

A few years ago I tried a desktop BSD distro called PC-BSD which used ZFS by default and the filesystem used literal gigabytes of ram. Idk, maybe these days things have improved in that regard, so please enlighten me if yes.

In all honestly, there's really absolutely no reason to use BugFS at all.

I know it's cool to hate on Btrfs to the point of making hyperbolic statements like these, but I've been using Btrfs for about 2 years now with zero stability issues whatsoever and as an average user, filesystem compression alone is a reason for me to use it.

[CHECK_12345]

Currently using BTRFS its good with the transparent compression with compress-force=zstd:1 on 3.5" 2TB 7200RPM HDD.

Arch Linux install with OpenBox with transparent compression:

compsize -x /

Processed 110329 files, 62215 regular extents (65159 refs), 68356 inline.
Type Perc Disk Usage Uncompressed Referenced
TOTAL 45% 1.7G 3.8G 4.1G
none 100% 612M 612M 618M
zstd 35% 1.1G 3.2G 3.5G
prealloc 100% 48K 48K 280K

This can be good for read performance, where the HDD has to read less.

Cant use mount BTRFS partiton created with I/O size higher than PAGE_SIZE set in Linux Kernel

I am unable to mount BTRFS partition created with I/O size higher than PAGE_SIZE set in Linux Kernel, and I not sure how to change PAGE_SIZE for x86_64 for Linux Kernel other than 4096kb so that I can test if having higher I/O would increase read speed on a HDD.

Being able to mount EXT4 partition created with higher I/O page size than higher PAGE_SIZE by using "bigalloc" feature

With EXT4 you could enable "bigalloc" feature when making the partition to be able to mount EXT4 partition that was created with higher I/O size than PAGE_SIZE set in Linux Kernel, havent tested how fast having higher I/O size with EXT4.