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

381–390 of 571 posts

Re: Linus: Don't Use ZFS

#381

Post by gigatexal »

natmaka wrote: post #325
tjoff wrote: post #84

Earlier quoted context omitted.

I feel ZFS are much better and easier than md or LVM. At least had it been properly supported (I have never tried ZoL). CoW and cheap snapshots are game-changers, checksums as well but maybe not from a practicality and home-user standpoint. This holds just as well on PB storage as a 512 GB OS drive as a 2 GB thumb-drive (not that I would use ZFS on a thumb drive - again because of proper support across different OS).

What about the performances, is ZFS in the same ballpark than an equivalent (data-protection-wise) 'md' layout?

There are ways to improve the perf but the copy on write arch does come with performance taxes in my experience. The trade off is a whole richer experience than a simple ext4 partition for example.

Re: Linus: Don't Use ZFS

#382

Post by gigatexal »

awused wrote: post #299
bayindirh wrote: post #57

Earlier quoted context omitted.

> people probably will, in a few years. Yes, but without the array as you stated. We have 300+ 10TB disks at our datacenter today and, ZFS is relevant at this disk count, I/O and client load. Running ZFS at small scale is raising a cow at home for a bucket of raw milk. It's more of a fun curiosity rather than a production level operation. I'd run LVM or md or something similar at home instead of a full blown ZFS setu…

I think ZFS - or at least the set of features ZFS provides - is relevant at any size or disk count all the way down to a single disk in a laptop. I've previously run ZFS on single block devices, though nowadays all my personal machines use at least ZFS mirroring. Without redundancy it can't recover from damage on its own, but checksums and free snapshots are irreplaceable to me. It doesn't have to be ZFS in particula…

Yeah if there was a similar GPL blessed effort that had most if not all of the main features of ZFS that was also robust and trust-able (likely takes years of use in production) I would be all for it. Projects like RedHat’s stratis might fill this. I’m not a ZFS zealot just love what it provides.

Re: Linus: Don't Use ZFS

#383

Post by boomboomsubban »

nottorp wrote: post #178
btilly wrote: post #35

Earlier quoted context omitted.

Here are his reasons for generally avoiding ZFS from what I consider most important to least. - The kernel team may break it at any time, and won't care if they do. - It doesn't seem to be well-maintained. - Performance is not that great compared to the alternatives. - Using it opens you up to the threat of lawsuits from Oracle. Given history, this is a real threat. (This is one that should be high for Linus but not…

> There is no conceivable reason that Oracle would want to threaten me with a lawsuit. I don't think it has to be conceivable with Oracle... Unfortunately I have to agree with Linus on this one. Messing with Oracle's stuff is dangerous if you can't afford a comparable legal team.

Linus is distributing the kernel, a very different beast from using a kernel module. I can't imagine Oracle targeting someone for using ZFS on Linux without first establishing that the distribution of ZFS on Linux is illegal.

Re: Linus: Don't Use ZFS

#384

Post by HorstG »

jordanbeiber wrote: post #274
HorstG wrote: post #107

Earlier quoted context omitted.

We had a bunch of Thumpers (SunFire X4200) with 48 disks at work, running ZFS on Solaris. It was dog slow and awful, tuning performance was complicated and took ages. One had to use just the right disks in just the right order in RaidZs with striping over them. Swap in a hotspare: things slow to a crawl (i.e. not even Gbit/s). After EoL a colleague installed Linux with dmraid, LVM and xfs on the same hardware: much f…

ZFS, on Solaris, not robust? ZFS for “play”?! This... is just plain uninformed. Not just me and my employer, but many (many) others rely on ZFS for critical production storage, and have done so for many years. It’s actually very robust on Linux as well - considering the fact that freeBSD have started to use the ZoL code base is quite telling. Would freeBSD also be in the “play” and “not robust” category as well, hang…

Performance wasn't robust, especially on dead disks and rebuilds, but also on pools with many (>100) filesystems or snapshots. Performance would often degrade heavily and unpredictably on such occasions. We didn't loose data more often than with other systems.

"play" comes from my distinct impression that the most vocal ZFS proponents are hobbyists and admins herding their pet servers (as opposed to cattle). ZFS comes at low/no cost nowadays and is easy to use, therefore ideal in this world.

Re: Linus: Don't Use ZFS

#385

Post by HorstG »

Annatar wrote: post #371
HorstG wrote: post #107

Earlier quoted context omitted.

We had a bunch of Thumpers (SunFire X4200) with 48 disks at work, running ZFS on Solaris. It was dog slow and awful, tuning performance was complicated and took ages. One had to use just the right disks in just the right order in RaidZs with striping over them. Swap in a hotspare: things slow to a crawl (i.e. not even Gbit/s). After EoL a colleague installed Linux with dmraid, LVM and xfs on the same hardware: much f…

"After EoL a colleague installed Linux with dmraid, LVM and xfs on the same hardware: much faster, more robust." Please let me know which company this is, so I can ensure that I never end up working there by accident. Much obliged in advance, thank you kindly.

Why? What is bad about playing around with leftover hardware?

Re: Linus: Don't Use ZFS

#386

Post by markvdb »

nottorp wrote: post #178
btilly wrote: post #35

Earlier quoted context omitted.

Here are his reasons for generally avoiding ZFS from what I consider most important to least. - The kernel team may break it at any time, and won't care if they do. - It doesn't seem to be well-maintained. - Performance is not that great compared to the alternatives. - Using it opens you up to the threat of lawsuits from Oracle. Given history, this is a real threat. (This is one that should be high for Linus but not…

> There is no conceivable reason that Oracle would want to threaten me with a lawsuit. I don't think it has to be conceivable with Oracle... Unfortunately I have to agree with Linus on this one. Messing with Oracle's stuff is dangerous if you can't afford a comparable legal team.

"Oracle's stuff" can most often be described more accurately as "what Oracle considers its stuff".

Re: Linus: Don't Use ZFS

#387

Post by bnastic »

m0zg wrote: post #46
blibble wrote: post #2

I'll give up Linux on my servers before I give up ZFS especially so given the recent petulant attitude that broke API compatibility in the LTS branch just to spite the ZFS developers: https://news.ycombinator.com/item?id=20186458 compete honestly on technical merit, rather than pulling dirty tricks that you'd expect of Oracle or 1990's MS

Pretty much my view as well. If Linux becomes incompatible with ZFS in any way, I'll switch to FreeBSD. That said, after the Oracle Java debacle, I can see why Linus would not be receptive towards merging ZFS into the kernel. I just wish he argued the point on legal issues alone instead of making up stories about non-existent technical flaws in ZFS. The whole thing is basically a work of art. Oracle should consider G…

> If Linux becomes incompatible with ZFS in any way, I'll switch to FreeBSD

Isn't FreeBSD now using ZFSOnLinux project as well?

Re: Linus: Don't Use ZFS

#388

Post by [deleted] »

ac29 wrote: post #295
liuliu wrote: post #166

Earlier quoted context omitted.

bcachefs should be heavily supported, it doesn't get nearly enough for what it supposes to do: https://www.patreon.com/bcachefs

Many of the advanced features aren't implemented yet though, like compression, encryption, snapshots, RAID5/6....

[deleted]

Re: Linus: Don't Use ZFS

#389

Post by tremon »

mschuster91 wrote: post #345
ac29 wrote: post #295

Earlier quoted context omitted.

Many of the advanced features aren't implemented yet though, like compression, encryption, snapshots, RAID5/6....

why would you want to embed raid5/6 in the filesystem layer? Linux has battle-tested mdraid for this, I'm not going to trust a new filesystem's own implementation over it. Same for encryption, there are already existing crypto layers both on the block and filesystem (as an overlay) level.

why would you want to embed raid5/6 in the filesystem layer?

There are valid reasons, most having to do with filesystem usage and optimization. Off the top of my head:

- more efficient re-syncs after failure (don't need to re-sync every block, only the blocks that were in use on the failed disk)

- can reconstruct data not only on disk self-reporting, but also on filesystem metadata errors (CRC errors, inconsistent dentries)

- different RAID profiles for different parts of the filesystem (think: parity raid for large files, raid10 for database files, no raid for tmp, N raid1 copies for filesystem metadata)

and for filesystem encryption:

- CBC ciphers have a common weakness: the block size is constant. If you use FS-object encryption instead of whole-FS encryption, the block size, offset and even the encryption keys can be varied across the disk.

Re: Linus: Don't Use ZFS

#390

Post by ilikejam »

morning_gelato wrote: post #337
ilikejam wrote: post #290

Earlier quoted context omitted.

There were genuine reasons for the CDDL - it wasn't an anti-gpl thing. https://www.youtube.com/watch?v=-zRN7XLCRhc&feature=youtu.be...

Danese Cooper, one of the people at Sun who helped create the CDDL, responded in the comment section of that very video: Lovely except it really was decided to explicitly make OpenSolaris incompatible with GPL. That was one of the design points of the CDDL. I was in that room, Bryan and you were not, but I know its fun to re-write history to suit your current politics. I pleaded with Sun to use a BSD family license o…

I stand corrected!
Post reply on HN