Live data from Hacker News

832 TB – ZFS on Linux

jonkensy.com

61–70 of 165 posts

Re: 832 TB – ZFS on Linux

#61
Zfs on linux and huge single servers, what could go wrong?

It's like a blog written by a 22 year old straight out of college that's never dealt with a real production deployment/failure

Zfs on Linux has data loss bugs. There's at least one unpatched and there are bound to be more.

Single huge servers eventually fail. Maybe it'll be a drive controller. Maybe it'll be CPU or ram with bit flips as a side effect. Downtime would be the least painful part of the eventual failure.

Re: 832 TB – ZFS on Linux

#62
post #53
post #49

Earlier quoted context omitted.

The ZFS comment in the document [1] is time inspecific. It's got version 1.0 in 1st half of 2018 and the "rough ZFS feature parity" comment is not until version 3.0, which has no listed time frame. This is going to take lot of work, and not just for the stratis developers but for projects that need to manipulate it. It's asking for a lot of work for bootloader projects to support it, and [1] https://stratis-storage.g…

Filesystems are HARD, see the plethora of FS's on Linux that are dead, dying, or horribly engineered. This seems like such a monumental waste of resources, time, and energy to chase ZFS, which itself is not a stationary target. ZFS is constantly developing new features. I think a lack of ZFS in Linux is hurting it. And that wound will only deepen over time.

Well obviously Linux devs would love having ZFS in the kernel, Linus even half joked that he'd consider trying to relicense Linux to GPLv3 if it meant he could use ZFS and DTrace (this was back when Sun was considering GPLv3 as the license to use when going open source).

But the problem remains, CDDL and GPL are likely incompatible, and Linus has said that no CDDL licensed code will be merged, most likely per advice from lawyers.

So unless something drastically changes, ZFS is off the table, and thus work will continue on with alternatives, Stratis is one such alternative, bcachefs is another, and of course btrfs will not die just because Red Hat isn't supporting it anymore, as they barely did to begin with.

Re: 832 TB – ZFS on Linux

#63
post #13
post #12

Earlier quoted context omitted.

Can you say what vendor you are using now?

Well, our vendor continues to be IX Systems (for the most part). However, instead of buying exclusively supermicro from them, we are now buying these Hitachi 60bay JBODs: http://www.hgst.com/products/platforms/4U60G2-storage-platfo... It really bugs that supermicro went this way. They used to be a very boring company that did nothing but build great chassis. I used to jokingly say that "supermicro is the rsync.net of…

> I used to jokingly say that "supermicro is the rsync.net of hardware".

a) I have never heard of rsync.net, and I doubt that many people have here

b) That sounds like a joke that is really funny at work, but really not funny on the internet at large

Just sayin'...

Re: 832 TB – ZFS on Linux

#64
post #10

Earlier quoted context omitted.

Yeah I was like uhhhh what? Illumos and illumos based OS'es and FreeBSD are the only games in town where ZFS is a first class citizen. Ill chalk it up to extreme bias.

Yeah, many people don't consider FreeBSD because of silly reasons… :( but mentioning Solaris that "requires licensing" and not illumos?? illumos is the new Solaris, the old Solaris devs are working on illumos! Oracle Solaris is irrelevant.

> Oracle Solaris is irrelevant.

Amen to that.

Re: 832 TB – ZFS on Linux

#65
post #51
post #48

Earlier quoted context omitted.

> For every competent FreeBSD or Illumos sysadmin there are 10x equally experienced with Linux. Was parent wrong about that point?

Not exactly, but to any competent administrator, learning FreeBSD based on Linux experience is not that difficult. It's sort of like tasking someone to start working on a program written in Go even if they have only C++ experience. You can cope.

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 obvious enough that a master Linux / C++ programmer will be productive and community standard-compliant without any effective lag time.

And I'm not trying to be obtuse. I honestly see it a lot and think it's a blind spot: reverse Pareto principle if you will. "Getting up to 80% proficiency is easy, so let's ignore the last 20% because it must also be easy."

Re: 832 TB – ZFS on Linux

#66
post #59
post #47

Earlier quoted context omitted.

There was an article a bit ago on HN where the Free Software Conservancy (?) wrote that legally, shipping a precompiled binary kernel module is the same as having it in the kernel.

But obviously Canonical's lawyers don't think shipping it separately is the same as shipping it in the kernel, because if they did they would not ship it separately to begin with.

Granted. But Canonical's lawyers are not canonical.

There's legal disagreement, and saying "Ubuntu did it" doesn't make those problems disappear. (Sadly)

Re: 832 TB – ZFS on Linux

#68
post #13

Earlier quoted context omitted.

Well, our vendor continues to be IX Systems (for the most part). However, instead of buying exclusively supermicro from them, we are now buying these Hitachi 60bay JBODs: http://www.hgst.com/products/platforms/4U60G2-storage-platfo... It really bugs that supermicro went this way. They used to be a very boring company that did nothing but build great chassis. I used to jokingly say that "supermicro is the rsync.net of…

> I used to jokingly say that "supermicro is the rsync.net of hardware". a) I have never heard of rsync.net, and I doubt that many people have here b) That sounds like a joke that is really funny at work, but really not funny on the internet at large Just sayin'...

a) your comment doesn't add anything to the discussion. b) you've obviously got some issues that you need to work out and the HN community shouldn't need to be exposed to them.

Re: 832 TB – ZFS on Linux

#69
post #66
post #59

Earlier quoted context omitted.

But obviously Canonical's lawyers don't think shipping it separately is the same as shipping it in the kernel, because if they did they would not ship it separately to begin with.

Granted. But Canonical's lawyers are not canonical. There's legal disagreement, and saying "Ubuntu did it" doesn't make those problems disappear. (Sadly)

>>But Canonical's lawyers are not canonical.

Hmm... not sure what you meant by this statement ?

Re: 832 TB – ZFS on Linux

#70
post #49

Earlier quoted context omitted.

The ZFS comment in the document [1] is time inspecific. It's got version 1.0 in 1st half of 2018 and the "rough ZFS feature parity" comment is not until version 3.0, which has no listed time frame. This is going to take lot of work, and not just for the stratis developers but for projects that need to manipulate it. It's asking for a lot of work for bootloader projects to support it, and [1] https://stratis-storage.g…

I'm friends with some of the original ZFS guys, Jeff Bonwick was a student of mine at Stanford and I got him to come to Sun, Bill Moore worked for me on BitKeeper. Those guys are seriously studly engineers. I've done file system work at Sun, I don't compare with Bill & Jeff, they are way better. So yeah, trying to do better than those guys is going to be interesting. I'd like to know who is on the RedHat team working…

XFS is the de facto standard file system for RHEL deployments, they employ a lot of engineers familiar with the code and it's the default since RHEL7 came out.
Post reply on HN