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

832 TB – ZFS on Linux

jonkensy.com

Post reply on HN
Print view View original

131–140 of 165 posts

Re: 832 TB – ZFS on Linux

#131

Post by cyphar »

X86BSD wrote: post #78
ethbro wrote: post #65

Earlier quoted context omitted.

I get a little annoyed with this line of reasoning though. "Anyone can learn anything" doesn't help me if I need an expert now . And it doesn't magically jump the gap between "functional" (I can make a thing work in an ugly and naive way) and "good" (I can weigh the trade-offs behind the scenes and choose the optimal from multiple alternatives). Unless the assertion is that FreeBSD / Go is easy, logical, and/or obvio…

I think your argument lies more in the fact that linux is non standard to Unix. They have gone their own way and made it difficult to transfer knowledge. Ask anyone who has ported a Linux application to any other Unix. It's at best a PITA. At worst a nightmare. Can you do it? Sure. But it isn't pleasant. The Linux community is off in the weeds imo. Doing their own poor re-implementations of tech others have already d…

That's not really a fair statement. First of all, Linux started as Linus just reimplementing the Unix semantics, so edge cases and subtle semantics should be expected to be different. Secondly, most Unix-based OSes are barely compatible in their facilities.

Sure, you have DTrace (which only macOS, illumos and FreeBSD have) and ZFS (which only illumos and FreeBSD have) but the rest is similarly incompatible. Solairs/illumos even has a complete NIH-reimplementation of FreeBSD's kqueue (event ports). They have different views on containerisation (Zones/Jails). They've historically had very different opinions on /proc and ioctls, not to mention that they were developed separately for such a long time that their shared history is not very recent.

As a result, porting from Solaris to FreeBSD is also difficult. Maybe it's harder or easier than porting to GNU/Linux, but I wouldn't just flat-out claim that GNU/Linux is the only member doing things that are incompatible.

Re: 832 TB – ZFS on Linux

#132

Post by raattgift »

jjirsa wrote: post #121
fnj wrote: post #95

Earlier quoted context omitted.

> Zfs on Linux has data loss bugs. Please don't spread untruths. Somebody who doesn't know better might actually believe you.

https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/160... Unpatched on 16.04, referenced as supported in the article

That was strictly speaking an openzfs bug that hit all the ports.

There's another one, somewhat related:

https://github.com/zfsonlinux/zfs/issues/6224

which (so far) seems tied to using recordsize > 128k without either of the -L or -c flags on the zfs send side, with the result that the sendstream is corrupted in such a way that the receiver cannot detect the corruption. As with the filled-holes problem, the problem is real but rare. Unlike the filled-holes problem, it is unlikely to affect many people since it is (probably) very rare that anyone uses large records and does not use -L (or -c, or both), although there are certainly automatic snapshot-send systems (e.g. znapzend) that use a common minimal set of options to zfs send.

This is especially unfortunate because of the rarity of the corruptions, the apparent rarity of people using POSIX-layer checksumming (e.g. rsync -c, or sha256deep or the like) on large datasets (with large files that had holes made and refilled, for example) to validate that a received dataset really is the same as the original, and the apparent rarity of people doing this sort of validation specifically targetting backwards compatibility mechanisms (e.g. zfs recv into a version 28 or earlier pool from a source dataset that uses all the most recent bells and whistles).

Finally, it is extra-especially unfortunate because recovering from this sort of corruption is awkward and time-consuming; at the minimum the source and destination have to be entirely read at least once or alternatively the destination needs to be destroyed and sent again from scratch once the fix or workaround for send|recv corruptions is known.

Re: 832 TB – ZFS on Linux

#133

Post by leonroy »

petre wrote: post #114
cmurf wrote: post #45

Earlier quoted context omitted.

SUSE has succeeded in shipping atomic OS updates and rollbacks by default both for enterprise and community versions of Linux several years ago. Facebook is using it, and the usage is growing. [1] And there are any number of examples of production usage of Btrfs at scale if you go look for them. [2] And the good and bad are fairly well understood, it is in fact getting better and will continue to get better.[3] And R…

Aren't Synology NAS devices also using Brtfs?

Yep, although they don't use Btrfs RAID but instead run it on top of LVM which provides the necessary RAID functionality.

Re: 832 TB – ZFS on Linux

#134

Post by fnj »

cyphar wrote: post #110
usefulcat wrote: post #107

Earlier quoted context omitted.

It sounds like you think you're disagreeing with me, but I'm not sure how that's possible given the near total lack of opinion in my post. In any case, the aspect of the parent comment that I was thinking of when I posted that was the part where the parent points out that Ubuntu has ZFS and how that could be a problem for RHEL. Yes RHEL offers a number of other FS options, but to my knowledge only ZFS and btrfs curre…

I disagree with the use of the word "deprecating", and everyone has been parroting around the news as though Red Hat announced that btrfs causes machines to catch on fire. Red Hat never provided enterprise support for btrfs, it was a technical preview that didn't pan out to become fully supported as part of their distribution. It's barely a story (there are plenty of other filesystems Red Hat doesn't support), but it…

> I disagree with the use of the word "deprecating"

Then you disagree (literally) with Red Hat's official statement as a matter of fact (not opinion). From Chapter 53, RHEL 7.4 release notes: "Btrfs has been deprecated ... Red Hat will not be moving Btrfs to a fully supported feature and it will be removed in a future major release of Red Hat Enterprise Linux."[0]

Pretty definitive.

[0] https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...

Re: 832 TB – ZFS on Linux

#135

Post by fnj »

greenhouse_gas wrote: post #109
gribbly wrote: post #41

Earlier quoted context omitted.

As I understand it, the license incompability between GPL and CDDL is that CDDL adds a restriction regarding patents, and GPL does not allow for additional restrictions to be added. So to distribute CDDL licensed code is a breach of BOTH licenses as I see it, ignoring the 'patent peace' requirement of CDDL which would be the case if distributing it as GPL does not sound legal to me (IANAL). I can certainly understand…

IANAL, but it (probably) depends on which license Canonical is using for the ZFS plugin. If they use CDDL, then I can't see how Oracle would have a case.

They can't legally use anything except CDDL. If anyone could just pick and choose to alter the licensing, there wouldn't be any point in having licences.

Re: 832 TB – ZFS on Linux

#136

Post by fnj »

tylerjl wrote: post #24
sandGorgon wrote: post #18

The most important line for me was "Today, you can run ZFS on Ubuntu 16.0.4.2 LTS with standard repositories and Canonical’s Ubuntu Advantage Advanced Support. That makes the decision easy." Its highly interesting that Canonical does this with ZFS. I'm not sure why they dont market this more.

I'm only a casual user of ZFS on Linux for personal storage projects, but I've spoken with people who rely very heavily on ZFS on Linux for their small businesses, and it's interesting to hear their perspectives on this. Essentially, because btrfs has failed to deliver on the next-gen filesystem front, ZFS on Linux is such a critical piece of technology that unless Red Hat has an answer soon for out-of-the-box ZFS on…

> One theory is that Canonical has essentially forced Oracle to decide whether it wants to crack down on inclusion of CDDL-licensed code being shipped with Ubuntu's stock kernel, so Red Hat may be waiting to see if Oracle sweeps in or not before following suit.

That is not a "theory" that anyone who understands the basics of the licenses adheres to. The possible threat is that linux' GPL could attack ZFS; not the other way round. There is nothing in the CDDL in the way of using ZFS in linux.

Re: 832 TB – ZFS on Linux

#137

Post by qaq »

rsync wrote: post #14
wmf wrote: post #8

Earlier quoted context omitted.

What specifically is the problem? Overpriced drives?

Yes. $30-$50 each. Multiply that by 60 or 90 and multiply that by (however many you put in a rack). That adds up to five figure premiums on drives we're going to burn in anyway . We know how to read an HCL - it's not rocket science.

Ok 60X50 is 3K even with extra 3K Supermicro is still a lot cheeper

Re: 832 TB – ZFS on Linux

#138

Post by ironMann »

andreiw wrote: post #37

I wish Supermicro had a similar chassis around the Cavium ThunderX. That would make a lot of sense for network-attached storage, regardless of whether one goes with SATA or drops in a SAS adapter or two. Does anyone know if any of the Cavium accelerators (crypto or compression) can improve ZFS perf?

Since ZoL 0.7, Raid-Z parity and checksumming (Fletcher4) operations are accelerated using SIMD instruction sets (in case of ThunderX, using aarch64 NEON)

Re: 832 TB – ZFS on Linux

#139

Post by fnj »

lottin wrote: post #46
georgyo wrote: post #30

Earlier quoted context omitted.

Oracle is not the one that could sue. There is nothing in the CDDL that prevents it being used else where. The GPL on the other hand is a strong copy left. If you link against GPL code, your code must also be licensed as GPL. This means the Linux copyright owners could sue the distributers of ZoL binaries, but Oracle could not. Oracle has the power to allow their ZFS code to be relicensed as GPL, removing this road b…

According to the Software Freedom Conservancy ...redistributing a binary work incorporating CDDLv1'd and GPLv2'd copyrighted portions constitutes copyright infringement in both directions... [ https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/ ] so it seems that Oracle could in fact sue.

> so it seems that Oracle could in fact sue.

Says the SFC. But Oracle has had plenty of time and they have not sued. In fact, they have not criticized Canonical for integrating ZFS.

Re: 832 TB – ZFS on Linux

#140

Post by ethbro »

johnwfinigan wrote: post #75
ethbro wrote: post #65

Earlier quoted context omitted.

I get a little annoyed with this line of reasoning though. "Anyone can learn anything" doesn't help me if I need an expert now . And it doesn't magically jump the gap between "functional" (I can make a thing work in an ugly and naive way) and "good" (I can weigh the trade-offs behind the scenes and choose the optimal from multiple alternatives). Unless the assertion is that FreeBSD / Go is easy, logical, and/or obvio…

Experts have to get made somehow. It's not as if Linux is a frozen target where you can count on being "productive and community standard-compliant without any effective lag time" without going back to the docs sometimes. A great example in my opinion: Red Hat RHEL7 introduced systemd. A lot changed versus RHEL6. RHEL6 "experts" turned into clumsy RHEL7 "80%-ers". We figured it out. Not to even mention that SuSE, RHE…

Absolutely. It happens. But to harken back to the original post, there are definite advantages to "technology with X experts available in the market" than "technology with Y experts available in the market". Where X > Y.

And those advantages don't disappear even if Y is easy to learn.

Post reply on HN