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

501–510 of 571 posts

Re: Linus: Don't Use ZFS

#501

Post by justincredible »

colonwqbang wrote: post #485
sandov wrote: post #225

Earlier quoted context omitted.

> drivers are expect to use the GPL if they want to be mainlined and maintained I think parent comment wasn't asking for third party, non-GPL drivers to be mainlined, but for a stable interface for out-of-tree drivers.

There is just no incentive for this that I can see. Linux is an open source effort. Linus had said that he considers open source "the only right way to do software". Out of tree drivers are tolerated, but the preferred outcome is for drivers to be open sourced and merged to the main Linux tree. The idea that Linux needs better support for out of tree drivers is like someone going to church and saying to the priest "I…

Jesus' body would be more delicious as a cookie.

Re: Linus: Don't Use ZFS

#502

Post by the8472 »

p_l wrote: post #176
the8472 wrote: post #62

Earlier quoted context omitted.

At least disk management is far easier with btrfs. You can restripe at will while zfs has severe limitations around resizing, adding and removing devices. Granted, at enterprise scale this hardly matters because you can just send-receive to rebuild pools if you have enough spares, but for consumer-grade deployments it's a non-negligible annoyance.

Restriping is source of unsafety, though. A lot of ZFS data safety comes from the fact it doesn't support overwriting anything, making it so that normal operation can't introduce unrecoverable corruption. In fact, all writes are done through snapshots.

ZFS wanted to have that too (the mythical block pointer rewrite) but it never happend, instead they add clunky workarounds like indirection tables for.

Re: Linus: Don't Use ZFS

#503

Post by zepearl »

amithanda81 wrote: post #491
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…

I agree with the stand btrfs, around same time (2 years back), it crashed on me while I was trying to use it for external hard disk attached to raspberry pi. nothing fancy. since then, I cant tolerate the fs crashes, for a user, its supposed to be one of the most reliable layers.

Concerning the BTRFS fs:

I did use it as well many years ago (probably around 2012-2015) in a raid5-configuration after reading a lot of positive comments about this next-gen fs => after a few weeks my raid started falling apart (while performing normal operations!) as I got all kind of weird problems => my conclusion was that the raid was corrupt and it couldn't be fixed => no big problem as I did have a backup, but that definitely ruined my initial BTRFS-experience. During those times even if the fs was new and even if there were warnings about it (being new), everybody was very optimistic/positive about it but in my case that experiment has been a desaster.

That event held me back until today from trying to use it again. I admit that today it might be a lot better than in the past but as people have already been in the past positive about it (but then in my case it broke) it's difficult for me now to say "aha - now the general positive opinion is probably more realistic then in the past", due e.g. to that bug that can potentially still destroy a raid (the "write hole"-bug): personally I think that if BTRFS still makes that raid-functionality available while it has such a big bug while at the same time advertising it as a great feature of the fs, the "irrealistically positive"-behaviour is still present, therefore I still cannot trust it. Additionally that bug being open since forever makes me think that it's really hard to fix, which in turn makes me think that the foundation and/or code of BTRFS is bad (which is the reason why that bug cannot be fixed quickly) and that therefore potentially in the future some even more complicated bugs might show up.

Concerning alternatives:

I am writing and testing since a looong time a program which ends up creating a big database (using "Yandex Clickhouse" for the main DB) distributed on multiple hosts where each one uses multiple HDDs to save the data and that at the same time is able to fight against potential "bitrot" ( https://en.wikipedia.org/wiki/Data_degradation ) without having to resync the whole local storage each time that a byte on some HDD lost its value. Excluding BTRFS, the only other candidate that I found is ZFSoL that perform checksums on data (both XFS and NILFS2 do checksums but only on metadata).

Excluding BTRFS because of the reasons mentioned above, I was left only with ZFS.

I'm now using ZFSoL since a couple of months and so far everything went very well (a bit difficult to understand & deal with at the beginning, but extremely flexible) and performance is as well good (but to be fair that's easy in combination with the Clickhouse DB, as the DB itself writes data already in a CoW-way, therefore blocks of a table stored on ZFS are always very likely to be contiguous).

On one hand, technically, now I'm happy. On the other hand I do admit that the problems about licensing and the non-integration of ZFSoL in the kernel do have risks. Unluckily I just don't see any alternative.

I do donate monthly something to https://www.patreon.com/bcachefs but I don't have high hopes - not much happening and BCACHE (even if currently integrated in the kernel) hasn't been in my experience very good (https://github.com/akiradeveloper/dm-writeboost worked A LOT better, but I'm not using it anymore as I don't have a usecase for it anymore, and it was a risk as well as not yet included in the kernel) therefore BCACHEFS might end up being the same.

Bah :(

Re: Linus: Don't Use ZFS

#504

Post by fgonzag »

Rapzid wrote: post #336
fgonzag wrote: post #37

Earlier quoted context omitted.

That's exactly why I said it's probably the only one that will get there.

Heh, BTRFS deja vu. Been hearing about the ZFS alternative "not quite there, but catching up" for about as long as high-speed rail. I wonder which will arrive first :)

BTRFS is never going to become stable. Ever. Just take a quick dive into the codebase.

Bcachefs has never had an unrecoverable data error AFAIK, even though it isn't even considered stable enough to merge into the kernel. The bcache on disk format won't be considered stable until he merges his code into mainline, though he doesn't feel he will need to adjust it further.

Features that currently work: Full data checksumming Compression Multiple device support Tiering/writeback caching RAID1/RAID10

All of these are stable, tested, and mostly bug free. Honestly, once the code gets mainlined you'll be able to start using it very quickly.

Main issue right now is performance, as it about as slow as BTRFS, which isn't inspiring. However the author has stated that he's going for correctness first, then he'll begin optimizing.

Re: Linus: Don't Use ZFS

#505

Post by shawnz »

bcrosby95 wrote: post #194
shawnz wrote: post #170

Earlier quoted context omitted.

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.

Proven legally necessary, as in, a court telling them to stop doing something? I'm pretty sure they don't want it to get to that point.

Proven legally necessary, as in, a court ever telling anyone in that situation to stop doing it. Or even to start doing it in the first place. There's just no legal justification behind it whatsoever.

Re: Linus: Don't Use ZFS

#506

Post by shawnz »

HorstG wrote: post #211
shawnz wrote: post #170

Earlier quoted context omitted.

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.

"Proven" is a maybe impossible standard: Kernel devs hint at the GPLonly exports having been useful in certain cases they prefer not to discuss on a ML. https://lore.kernel.org/lkml/20190110131132.GC20217@kroah.co... One can interpret this as something legally significant, or an embarrassing private anecdote, or nothing substantial at all, maybe even just talk. However, I'd give them the benefit of the doubt. Not the…

What he is referring to is the use of the GPL export restriction to strong-arm companies into releasing their code as GPL. It's nothing to do with a legal requirement, he is just an open source licensing hardhead. See: https://lwn.net/Articles/603145/

Re: Linus: Don't Use ZFS

#507

Post by kasabali »

phyzome wrote: post #89

Until I have a viable alternative that gives me snapshotting (so I can make consistent backups), that advice is worthless to me.

LVM snapshots has been good enough for consistent backups for the last 20 years. Then there is also thin snapshots if you feel fancy.

Re: Linus: Don't Use ZFS

#508

Post by Wowfunhappy »

cycloptic wrote: post #486
Wowfunhappy wrote: post #458

Earlier quoted context omitted.

Sorry for using the term "zealots", I didn't intend it as a pejorative. I should probably have said "hardliners". I meant only to refer to people at the extreme end of the spectrum on this issue. > The root of the question is "What determines a change to the software". [...] The answers to these questions are not well defined. And that's fair, but what confuses me is that I never see this question raised on non-Linux…

>No one considers Windows drivers a derivative of Windows, or Mac kernel extensions a derivative of Darwin. Perhaps they do, but the difference is that their licensing does not regard their status of derivative works as being important. Those platforms have their own restrictions on what drivers they want to allow. In particular, Mac doesn't even allow unsigned drivers anymore, and any signed drivers have to go throu…

Thank you!

Just to clarify one little thing, because it appears to be something of a common misconception:

> Mac doesn't even allow unsigned drivers anymore

You can absolutely still install unsigned drivers (kernel extensions) on macOS, the user just needs to run a Terminal command from recovery mode. This is a one-time process that takes all of five minutes if you know what you're doing.

You can theoretically replace the Darwin kernel with your own version too. macOS is not iOS, you can completely open it up if you want.

Re: Linus: Don't Use ZFS

#509

Post by MaxBarraclough »

fierarul wrote: post #315
MaxBarraclough wrote: post #17

Earlier quoted context omitted.

OpenJDK is on pretty solid legal ground, no?

Haha, OpenJDK is wholly owned by Oracle. There is no separate legal entity. License wise it's GPL w/ CPE.

Plus the OpenJDK Community TCK Licensing Agreement.

No-one's seriously concerned that adopting OpenJDK could land them in legal trouble, as far as I know. I don't think a separate legal entity is always necessary.

Re: Linus: Don't Use ZFS

#510

Post by notacoward »

throw0101a wrote: post #469
notacoward wrote: post #422

Earlier quoted context omitted.

> when you read, zfs will check the data on both and pick the correct one. Are you sure about that? Always reading both doubles read I/O, and benchmarks show no such effect. > there's no way for the fs to tell which is correct This is not an immutable fact that precludes keeping the RAID implementation separate. If the FS reads data and gets a checksum mismatch, it should be able to use ioctls (or equivalent) to sele…

> This supposed need for ZFS to absorb all RAID/LVM/page-cache behavior into itself is a myth; what really happened is good old-fashioned NIH. At the time that ZFS was written (early 2000s) and released to the public (2006), this was not a thing and the idea was somewhat novel / 'controversial'. Jeff Bonwick, ZFS co-creator, lays out their thinking: * https://blogs.oracle.com/bonwick/rampant-layering-violation Rememb…

I debated some of this with Bonwick (and Cantrill who really had no business being involved but he's pernicious that way) at the time. That blog post is, frankly, a bit misleading. The storage "stack" isn't really a stack. It's a DAG. Multiple kinds of devices, multiple filesystems plus raw block users (yes they still exist and sometimes even have reason to), multiple kinds of functionality in between. An LVM API allows some of this to have M users above and N providers below, for M+N total connections instead of M*N. To borrow Bonwick's own condescending turn of phrase, that's math. The "telescoping" he mentions works fine when your storage stack really is a stack, which might have made sense in a not-so-open Sun context, but in the broader world where multiple options are available at every level it's still bad engineering.
Post reply on HN