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

Linus: Don't Use ZFS

realworldtech.com

Post reply on HN
Print view View original

361–370 of 571 posts

Re: Linus: Don't Use ZFS

#361

Post by XelNika »

berti wrote: post #230
HorstG wrote: post #206

Earlier quoted context omitted.

Some features such as Raid5 were still firmly in "don't use if you value your data" territory last I looked. So it is important to be informed as to what can be used and what might be more dangerous with btrfs

Keep in mind that RAID5 isn’t feasible with multi-TB disks (the probability of failed blocks when rebuilding the array is far too high). That said, RAID6 also suffers the same write-hole problem with Btrfs. Personally I choose RAIDZ2 instead.

> Keep in mind that RAID5 isn’t feasible with multi-TB disks (the probability of failed blocks when rebuilding the array is far too high).

What makes you say that? I've seen plenty of people make this claim based on URE rates, but I've also not seen any evidence that it is a real problem for a 3-4 drive setup. Modern drives are specced at 1 URE per 10^15 bits read (or better), so less than 1 URE in 125 TB read. Even if a rebuild did fail, you could just start over from a backup. Sure, if the array is mission critical and you have the money, use something with more redundancy, but I don't think RAID5 is infeasible in general.

Re: Linus: Don't Use ZFS

#362

Post by josefx »

zamalek wrote: post #310
pizza234 wrote: post #132

Earlier quoted context omitted.

I'm baffled by such arguments. > It doesn't seem to be well-maintained. The last commit is from 3 hours ago: https://github.com/zfsonlinux/zfs/commits/master . They have dozens of commits per month. The last minor release, 0.8, brought significant improvements (my favorite: FS-level encryption). Or maybe this is referred to the 5.0 kernel (initial) incompatibility? That wasn't the ZFS dev team's fault. > Performance…

> ZFS has a CDDL license Java is GPLv2+CPE. That didn't stop Oracle because, as Linus pointed out in the email, Oracle regards their APIs as a separate entity to their code.

Googles Java implementation wasn't GPL licensed, so neither its implementation nor its interface could have been covered by the OpenJDK being GPLv2. I think RMS wouldn't sit by idly either if someone took GCC and forked it under the Apache license.

Re: Linus: Don't Use ZFS

#363

Post by ZoomZoomZoom »

jessant wrote: post #33
fgonzag wrote: post #25

Earlier quoted context omitted.

Bcachefs is probably the only thing that will get there. The codebase is clean and we'll mantained, built from solid technology (bcache) and will include most of the ZFS niceties. I just wish more companies would sponsor de project and stop wasting money on BTRFS

Snapshots don't seem to be done yet.

They're being worked on ATM: Dec 29, 2019 "Just finished a major rework that gets us a step closer to snapshots: the btree code is incrementally being changed to handle extents like regular keys." https://www.patreon.com/posts/towards-32698961

Re: Linus: Don't Use ZFS

#364

Post by scoutt »

Maybe offtopic, but I'm impressed by the rest of the conversation that generated that message from Linus: there is a whole thread in which Linus gets to explain with detail various locking mechanism in the kernel, pros and cons, etc.

I think we don't see this normally happening; situations in which the (technical) responsible for the Apple or MS kernels get to answer question and explain with such level of detail.

I think also that is even more interesting than the original blog post that originated that thread. Someone should harvest all these Linus comments and order them in some kind of "lectures" library.

Re: Linus: Don't Use ZFS

#365

Post by Annatar »

m4rtink wrote: post #190
stock_toaster wrote: post #150

Earlier quoted context omitted.

> - Performance is not that great compared to the alternatives. CoW filesystems do trade performance for data safety. Or did you mean there are other _stable/production_ CoW filesystems with better performance? If so, please do point them out!

XFS on LVM thin pool LV. Stable and performant as far as I can tell.

XFS is not copy on write.

Re: Linus: Don't Use ZFS

#366

Post by ailideex »

anon73044 wrote: post #69
m463 wrote: post #16

Earlier quoted context omitted.

"Don't use ZFS. It's that simple. It was always more of a buzzword than anything else, I feel, and the licensing issues just make it a non-starter for me." When he says that, I think on the $500 million Sun spent on advertising java.

Sun isn't going to sue anyone into oblivion any time soon, but Oracle sure will

Sun is all but defunct, I don't think I would characterize it as a subsidiary of Oracle.

Re: Linus: Don't Use ZFS

#368

Post by merlincorey »

kova12 wrote: post #335
merlincorey wrote: post #146

Earlier quoted context omitted.

> ZFS partitions are also almost impossible to resize I'm not sure you've actually used ZFS very much as any way I can see you could be meaning this, it is actually pretty straightforward and simple to resize partitions with ZFS pools and volumes within ZFS pools. For example, if you mean that you have a root zpool on a device using only half the device, you just have to resize the partition and then turn on `autoexp…

We are talking about something resembling adding an extra disk to raid5. Can be easily done in mdadm raid, and then you just need to resize lvm, or whatever you run over it. Can not be done in zfs, not in raid5/6 mode

You're confusing extending vdevs with extending pools and stripes.

It's kind of apples to oranges, really.

FreeNAS documentation[0] makes it pretty clear.

In ZFS, you cannot add devices to a vdev after it has been created -- however, you CAN add more vdevs to a pool.

So basically, your complaint is that ZFS wants to have stripes of vdevs and that instead of adding 1 drive to a 3 drive RAID5 to make a 4 drive RAID5, you have to add 3 drives to a RAIDZ1 for a 6 drive RAIDZ+0 that is equivalent to a RAID50 on a hardware controller.

Yes, it's more enterprisey, but it's not especially more difficult and the result is different and perhaps better depending on your use case.

Re: Linus: Don't Use ZFS

#369

Post by PopeDotNinja »

barrkel wrote: post #251
zelly wrote: post #138

He's not wrong. ext4 is actually maintained. This matters. ZFS hasn't kept up with SSDs. ZFS partitions are also almost impossible to resize, which is a huge deal in today's world of virtualized hardware. Honestly Linus's attitude is refreshing. It's a sign that Linux hasn't yet become some stiff design-by-committee thing. One guy ranting still calls the shots. I love it. Protect this man at all costs.

He is wrong. He's focused on performance; people use ZFS for its features, not its performance.

At works we used ZFS w/ snapshots for a container build machine for performance reasons. We had some edge cases that made the Docker copy on write filesystem unsuitable.

Re: Linus: Don't Use ZFS

#370

Post by m-ueberall »

jauer wrote: post #316
disordinary wrote: post #202

Earlier quoted context omitted.

There's differing opinions of BTRFS's suitability in production - it's the default filesystem of SUSE on one hand, on the other RedHat has deprecated BTRFS support because they see it as not being production ready and they don't see it being production ready in the near future. They also feel that the more legacy linux filesystems have added features to compete.

Facebook runs on btrfs: https://facebookmicrosites.github.io/btrfs/docs/btrfs-facebo...

But then, your personal requirements/use cases might not be the same as Facebook's. (And this does not only apply to Btrfs[1]/ZFS, it also applies to GlusterFS, use of specific hardware, ...)

[1] which I used for nearly two years on a small desktop machine on a daily basis; ended up with (minor?) errors on the file system that could not be repaired and decided to switch to ZFS. No regrets, nor similar errors since.

Post reply on HN