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

201–210 of 571 posts

Re: Linus: Don't Use ZFS

#201

Post by zippergz »

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…

I have been using FreeBSD for its better ZFS support for years, and it's great. Highly recommended.

Re: Linus: Don't Use ZFS

#202

Post by disordinary »

LaGrange wrote: post #154
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…

> There are no (stable) alternatives. BTRFS certainly not, as it's "under heavy development"¹ (since... forever). Note that they don't mean "it's unstable," just "there are significant improvements between versions." Most importantly: > The filesystem disk format is stable; this means it is not expected to change unless there are very strong reasons to do so. If there is a format change, filesystems which implement t…

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.

Re: Linus: Don't Use ZFS

#203

Post by denimboy »

esoterae wrote: post #161
wazoox wrote: post #130

Earlier quoted context omitted.

ZFS performs quite well if you give it boatloads of RAM. It uses its own cache layer, and eats RAM like hotcakes. XFS OTOH is as fast as the hardware can go with any amount of RAM.

Sort of. But no snapshots. Wanna use LVM for snapshots? 33% performance hit for the entire LV per snapshot, by implementation. ZFS? ~1% hit. I've never been able to see any difference at the workloads I run, whereas with LVM it was pervasive and inescapable.

I don't doubt this but do you have any documentation?

Asking for a friend who uses XFS on LVM for disk heavy applications like database, file server, etc.

Re: Linus: Don't Use ZFS

#204

Post by XorNot »

annoyingnoob wrote: post #188
yjftsjthsd-h wrote: post #23

Alright, Linus, I'll make you a deal: I'll consider dropping ZFS when you ship a production-grade BTRFS (or reiserfs or anything else with the same features).

Is reiserfs still maintained. After Hans went to prison I didn't think there was much left beyond stagnation.

They really needed to rename it.

Re: Linus: Don't Use ZFS

#205

Post by hunta2097 »

HorstG wrote: post #165
__jal wrote: post #134

Earlier quoted context omitted.

Sounds like you turned on dedupe, or had an absurdly wide stripe size. You do need to match your array structure to your needs as well as tune ZFS. On our backup servers (45 disks, 6-wide Z2 stripes) easily handle wire-speed 10G with 32G ARC. And you're just wrong about snapshots and filesystem counts. ZFS is no speed demon, but it performs just fine if you set it up correctly and tune it.

Stripe size could have been a problem, though we just went with the default there afair. Most of the first tries was just along the Sun docs, we later only changed things until performance was sufficient. Dedupe wasn't even implemented back then. Maybe you also don't see as massive an impact because your hardware is a lot faster. X4200s were predominantly meant to be cheap, not fast. No cache, insufficient RAM, slow…

X4200s were the devil's work. Terrible BMC, raid controller, even the disk caddies were poorly designed.

The BMC controller couldn't speak to the disk controller so you had no out-of-band storage management.

I had to Run a fleet of 300 of them, truly an awful time.

Re: Linus: Don't Use ZFS

#206

Post by HorstG »

LaGrange wrote: post #154
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…

> There are no (stable) alternatives. BTRFS certainly not, as it's "under heavy development"¹ (since... forever). Note that they don't mean "it's unstable," just "there are significant improvements between versions." Most importantly: > The filesystem disk format is stable; this means it is not expected to change unless there are very strong reasons to do so. If there is a format change, filesystems which implement t…

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

Re: Linus: Don't Use ZFS

#207

Post by zlynx »

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.

My terrible experiences with thin pools makes me see btrfs as a pool of wonderful, trouble-free and perfect code.

Just ask yourself what happens when a thin pool runs out of actual, physical disk blocks?

Re: Linus: Don't Use ZFS

#209

Post by teddyuk »

shawnz wrote: post #170
throwaway6779 wrote: post #168

Earlier quoted context omitted.

If I remember correctly, the reasoning for the GPL module stuff was/is, that if kernel modules integrate deeply with the kernel, they fall under gpl. So the GPL flag is basically a guideline of what kernel developers believe is safe to use from non gpl-compatible modules

This is the commonly recited argument but I don't believe it was ever proven to be legally necessary. Furthermore, even if it was, it's not clear what level of integration is "too deep". So in practice, it's just a way for kernel developers to add political restrictions as they see fit.

Surely the kernel developers can do whatever the hell they like.

If you don’t like that don’t use it.

Post reply on HN