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

471–480 of 571 posts

Re: Linus: Don't Use ZFS

#471

Post by admax88q »

notacoward wrote: post #453
wolfgke wrote: post #435

Earlier quoted context omitted.

> Sun was never as open or innovative as its engineer/advertisers claim, and the revisionism is irksome. For (the lack of) openness, I agree, but the claim that they were not innovative needs stronger evidence.

Just to be clear, I'm not saying they weren't innovative. I'm saying they weren't as innovative as they claim. Apollo, Masscomp, Pyramid, Sequent, Encore, Stellar, Ardent, Elxsi, Cydrome, and others were also innovating plenty during Sun's heyday, as were DEC and even HP. To hear ex-Sun engimarketers talk, you'd think they were the only ones. Reality is that they were in the mix. Their fleetingly greater success had…

Java was pretty innovative. The worlds most advanced virtual machine, a JIT that often outperforms C in long running server scenarios, and the foundation of probably 95% of enterprise software.

Re: Linus: Don't Use ZFS

#472

Post by danw1979 »

Polite reminder that Kent Overstreet is still plugging away at a new copy-on-write FS for Linux called bcachefs. One day, I hope it'll replace ZFS for my uses.

I'm not involved with the project in any way, apart from sending him a few bucks a month on patreon. It's literally the only open source thing I sponsor; it seems like a really worthwhile effort especially considering Linus' advice here...

Re: Linus: Don't Use ZFS

#473

Post by arminiusreturns »

reacharavindh wrote: post #10

As a heavy user of ZFS and Linux, what else is there that even comes close to what ZFS offers? I want cheap and reliable snapshots, export & import of file systems like ZFS datasets, simple compression, caching facilities(like SLOG and ARC) and decent performance.

So besides the obvious btrfs answer, what about ceph as clustered storage with very fast connectivity?

There is also BeeGFS, I haven't used it but /r/datahoarders sometimes touts it.

Not for linux but I have been keeping an eye on M Dillons DragonFly BSD where he has been working on HAMMER2, which is very interesting.

I don't know much but bcachefs has been making more waves lately also.

I think the bottom line is that people need to have good backup in place regardless.

Re: Linus: Don't Use ZFS

#474

Post by throw0101a »

notacoward wrote: post #433
rhinoceraptor wrote: post #432

Earlier quoted context omitted.

The fact that traditionally RAID, LVM, etc. are not part of the filesystem is just an accident of history. It's just that no one wanted to rewrite their single disk filesystems now that they needed to support multiple disks. And the fact that administering storage is so uniquely hard is a direct result of that.

However it happened, modularity is still a good thing. It allows multiple filesystems (and other things that aren't quite filesystems) to take advantage of the same functionality, even concurrently, instead of each reinventing a slightly different and likely inferior wheel. It should not be abandoned lightly. Is "modularity bad" really the hill you want to defend?

> However it happened, modularity is still a good thing.

It may be a good thing, and it may not. Linux has a bajillion file systems, some more useful than others, and that is unique in some ways.

Solaris and other enterprise-y Unixes at the time only had one. Even the BSDs generally only have a few that they run on instead of ext2/3/4, XFS, ReiserFS (remember when that was going to take over?), btrfs, bcachefs, etc, etc, etc.

At most, a company may have purchased a license for Veritas:

* https://en.wikipedia.org/wiki/Veritas_Storage_Foundation

By rolling everything together, you get ACID writes, atomic space-efficient low-overhead snapshots, storage pools, etc. All this just be removing one layer of indirection and doing some telescoping:

* https://blogs.oracle.com/bonwick/rampant-layering-violation

It's not "modularity bad", but that to achieve the same result someone would have had to write/expand a layer-to-layer API to achieve the same results, and no one did. Also, as a first-order estimate of complexity: how many lines of code (LoC) are there in mdraid/LVM/ext4 versus ZFS (or UFS+SVM on Solaris).

Re: Linus: Don't Use ZFS

#475

Post by HorstG »

sokoloff wrote: post #408
HorstG wrote: post #233

Earlier quoted context omitted.

I think the optimal number of RAIDz5 disks is 3, if you just want performance. But this wastes lots of space of course. Also, the number of SAS/SATA-channels per controller and the topology of expanders is important. Thats why I don't think there is a recipy, you have to try it out for each new kind of hardware. And as another thread pointed out, stripe size is also an important parameter.

I think you mean RAIDZ1, not 5.

Yes. RAIDz (without the "1") was the original RAID5-equivalent, RAIDz2 is equivalent to RAID6. However since nobody really knows what the hell z1 and z2 is and z1 is easy to mix up with RAID1 for nonZFS people, calling it z5 and z6 is far less confusing.

Re: Linus: Don't Use ZFS

#476

Post by celticmusic »

omegabravo wrote: post #397
anoncake wrote: post #227

Earlier quoted context omitted.

Is that experience recent? AMD drivers used to be terrible and Intel isn't even competition.

I'm currently running a AMD card because I thought the drivers were better. I was mistaken, I still have screen tearing that I can't fix. No doubt someone more knowledgeable about Linux could fix this issue, but I never had any issues with my nVidia blobs. That's not to say nVidia don't have their own issues.

this was my experience as well. I eventually bought an NVidia card to replace it so I could stop having problems. It's been smooth ever since.

Re: Linus: Don't Use ZFS

#477

Post by HorstG »

awused wrote: post #449
HorstG wrote: post #394

Earlier quoted context omitted.

ZFS does overprovision all filesystems in a zpool by default. Create 10 new filesystems and 'df' will now display 10x the space of the parent fs. A full fs is handled differently than your volume manager running out of blocks. But the normal case is overprovisioning.

That is not over-provisioning, it's just that 'df' doesn't have the concept of pooled storage. With pools it's possible for different file systems to share their "available" space. BTRFS also has its own problems with ouput when using df and getting strange results. If I have a 10GB pool and I create 10 empty file systems, the sizes reported in df will be 100GB. It's not quite a lie either, because each of those 10 f…

This is exactly what overprovisioning is: The sum of possible future allocations is greater than available space.

Re: Linus: Don't Use ZFS

#478

Post by forgotpwd16 »

phire wrote: post #159
forgotpwd16 wrote: post #111

Earlier quoted context omitted.

>stop wasting money on BTRFS You're saying they should stop supporting a project that was considered stable by the time the other started being developed. Why do that? What makes Bcachefs a better choice?

I don't think BTRFS has ever been considered stable. I think they just said: "The on-disk data structure is stable" and lots of people misinterpreted that as "the whole thing is stable" A stable on-disk data structure just means it's been frozen and can't be changed in non-backwards compatible ways. It says nothing about code quality, feature completeness or if the frozen data structure was any good.

The finalization of the on-disk data structure came soon after Btrfs was announced and happened before 2010. I meant that by 2010s when Bcachefs started development, Btrfs was considered a supported filesystem for "big name" server distros such as Oracle and SUSE.

Re: Linus: Don't Use ZFS

#479

Post by goatinaboat »

stiray wrote: post #321
Jonnax wrote: post #4

Here's his reasoning: "honestly, there is no way I can merge any of the ZFS efforts until I get an official letter from Oracle that is signed by their main legal counsel or preferably by Larry Ellison himself that says that yes, it's ok to do so and treat the end result as GPL'd. Other people think it can be ok to merge ZFS code into the kernel and that the module interface makes it ok, and that's their decision. But…

Btrfs crashed for me on two occations, last time, around 2 years back I have installed zfs (which I am using for ~10 years on FreeBSD server) which works like a charm since then. I understand Linus reasoning but there is just no way I will install btrfs, like ever. I rather dont update kernel (I am having zfs on fedora root with degular kernel updates and scripts which verify that everything is with kernel modules pr…

Btrfs like OCFS is pretty much junk. You can do everything you need to on local disk with XFS and if you need clever features buy a NetApp.

Re: Linus: Don't Use ZFS

#480

Post by stiray »

blacklight wrote: post #470
stiray wrote: post #321

Earlier quoted context omitted.

Btrfs crashed for me on two occations, last time, around 2 years back I have installed zfs (which I am using for ~10 years on FreeBSD server) which works like a charm since then. I understand Linus reasoning but there is just no way I will install btrfs, like ever. I rather dont update kernel (I am having zfs on fedora root with degular kernel updates and scripts which verify that everything is with kernel modules pr…

The Linux kernel has been released under GPL2 license since day 1, and I don't think that's ever going to change. Linus is more pragmatic than many of his detractors think - he thankfully refused to migrate to GPL3 because the stricter clauses would have scared away a lot of for-profit users and contributors. Relaxing on anything more permissive than GPL2 would instead mean the end of Linux as we know it. A more perm…

The blame is on Oracle side for sure. No question about it.

> or replacing the source code of most of the modules with hex bloats.

Ok good point, I am no longer pissed off on MODULE_LICENSE, didn't even thought about that.

Post reply on HN