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

101–110 of 165 posts

Re: 832 TB – ZFS on Linux

#101

Post by cmurf »

luckydude wrote: post #76
snuxoll wrote: post #70

Earlier quoted context omitted.

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.

Do you know if they have any of the SGI team? Like Adam and/or Mike?

    $ git log --since=”2016-01-01” --pretty=format:”%an” --no-merges -- fs/xfs | sort -u
https://pastebin.com/0Yv5giDK

XFS history https://lwn.net/Articles/638546/

Linux file systems, where did they come from? (Presented by Dave Chinner who has been XFS maintainer for a few years.) https://www.youtube.com/watch?v=SMcVdZk7wV8

Re: 832 TB – ZFS on Linux

#102

Post by [deleted] »

exikyut wrote: post #85
jjirsa wrote: post #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. Downtim…

I'm planning on doing a tiny ZFS pool (once I've finally saved up for it - financials can be fun sometimes!), and was thinking of doing FreeBSD for ZFS and Linux for everything else on top of Xen. I'm currently unsure how to make Linux see the ZFS pool though. I.... don't really like NFS. It's too glitchy in my experience. I use it to listen to music stored on a different machine from my laptop, which uses a long-ran…

[deleted]

Re: 832 TB – ZFS on Linux

#103

Post by [deleted] »

patrickg_zill wrote: post #79
jjirsa wrote: post #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. Downtim…

Actually the real issue is, "when the system is 65% full and you reboot, how long will it take for ZFS to mount it"? Perhaps he has split up ZFS into a number of different pools and they can be mounted in parallel (depends on the init script and whether ZFS can do this). But I do recall that larger ZFS pools can take a bit of time to mount; maybe the updated ZFS for Linux is faster....

[deleted]

Re: 832 TB – ZFS on Linux

#104

Post by cmurf »

cyphar wrote: post #94
usefulcat wrote: post #81

Earlier quoted context omitted.

RHEL is not continuing to bet on btrfs; they are deprecating it: https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...

As was explained in depth in the HN comments, Red Hat's decision to not provide enterprise support is based on the fact that they don't have the necessary engineers to backport and maintain one of the fastest moving pieces of code in Linux today. All of their btrfs engineers moved to Facebook, and they're still working on btrfs improvements. There are many decisions involved in deciding what to provide enterprise sup…

    $ git log --since=”2016-01-01” --pretty=format:”%an” --no-merges -- fs/btrfs | sort -u
And then iterate for ext4 and xfs, and that comes to: 100 btrfs, 71 ext4, and 63 XFS contributors over those 18 months. They are all healthy ecofilesystems.

Re: 832 TB – ZFS on Linux

#105

Post by feedbeef »

rsync wrote: post #13
dsl wrote: 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'm wondering who signed off on your website. Consider nixing the forced scrolling and/or preventing the header from covering your copy (http://rsync.net/#secondpage).

Re: 832 TB – ZFS on Linux

#106

Post by Spivak »

atmosx wrote: post #80
notpeter wrote: post #21

Earlier quoted context omitted.

It's likely a human resources problem. For every competent FreeBSD or Illumos sysadmin there are 10x equally experienced with Linux. And those numbers are much worse outside of major cities. The commercial support from Ubuntu tips the scales. I made this same decision at my last job. I ran Solaris and Illumos on our file servers and loved it, but a year before I left I ported all the pools to Ubuntu so my successor o…

> For every competent FreeBSD or Illumos sysadmin there are 10x equally experienced with Linux That's the Nth I've read this quote on HN, it became a classic... You can't find a FreeBSD sysadmin but you can find a Linux admin. Where I work I have to deal with AIX, Solaris, Open/FreeBSD (Had Net before), Linux (all major flavours) and (god Forbid) Windows Server (2008, 12R2, 2016 and Nano). I've build packages for mos…

It's hard enough to find Linux admins, even in major cities. There are people who will put Linux experience on their resumes, but almost nobody who can boast more than casual home use. We ended up giving up on finding a Linux admin after a few months of the job posting collecting dust and decided to just hire someone fresh out of college a train them from scratch.

Then you run into the problem that BSD admins are even rarer, and AIX/Solaris even rarer than that.

Someone with experience with Linux could likely find their way around any UNIX like system but given the choice we would rather deal with some awkwardness in a familiar environment where admins have far more experience and we can leverage our exiting infrastructure, scripts, and config management.

Re: 832 TB – ZFS on Linux

#107

Post by usefulcat »

cyphar wrote: post #94
usefulcat wrote: post #81

Earlier quoted context omitted.

RHEL is not continuing to bet on btrfs; they are deprecating it: https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...

As was explained in depth in the HN comments, Red Hat's decision to not provide enterprise support is based on the fact that they don't have the necessary engineers to backport and maintain one of the fastest moving pieces of code in Linux today. All of their btrfs engineers moved to Facebook, and they're still working on btrfs improvements. There are many decisions involved in deciding what to provide enterprise sup…

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 currently offer checksumming, which IMO is a big differentiator vs. more conventional filesystems.

Re: 832 TB – ZFS on Linux

#108

Post by walrus »

ams6110 wrote: post #91
jjirsa wrote: post #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. Downtim…

My (admittedly limted) experience with ZFS has been bad. I know it's supposed to be great but that is not what I have experienced. Multi-hour outages. Having to have Oracle help resolve problems. This was a few year ago now, maybe it's better these days. I was not the administrator, just a user, but we had ZFS issues at least quarterly on a ~20TB shared filesystem on a Linux cluster.

Was ZFS determined to be the problem in the root cause analysis, or was it another part of the storage system that failed? It's easy to pass the blame down to the lowest level of the system because no one wants to take the blame.

If it was actually determined to be the fault of ZFS, what was the problem? I'd like to avoid it in my own deployment.

Re: 832 TB – ZFS on Linux

#109

Post by greenhouse_gas »

gribbly wrote: post #41
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…

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.

Re: 832 TB – ZFS on Linux

#110

Post by cyphar »

usefulcat wrote: post #107
cyphar wrote: post #94

Earlier quoted context omitted.

As was explained in depth in the HN comments, Red Hat's decision to not provide enterprise support is based on the fact that they don't have the necessary engineers to backport and maintain one of the fastest moving pieces of code in Linux today. All of their btrfs engineers moved to Facebook, and they're still working on btrfs improvements. There are many decisions involved in deciding what to provide enterprise sup…

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's a good opportunity to spread misinformation.

Post reply on HN