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

481–490 of 571 posts

Re: Linus: Don't Use ZFS

#481

Post by notacoward »

admax88q wrote: post #471
notacoward wrote: post #453

Earlier quoted context omitted.

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.

ANDF had already done (or at least tried to do) the "write once, run anywhere" thing. The JVM followed in the footsteps of similar longstanding efforts at UCSD, IBM and elsewhere. There was some innovation, but "world's most advanced virtual machine" took thousands of people (many of them not at Sun) decades to achieve. Sun's contribution was primarily in popularizing these ideas. Technically, it was just one more step on an established path.

Re: Linus: Don't Use ZFS

#482

Post by lolc »

rhinoceraptor wrote: post #426
mschuster91 wrote: post #345

Earlier quoted context omitted.

why would you want to embed raid5/6 in the filesystem layer? Linux has battle-tested mdraid for this, I'm not going to trust a new filesystem's own implementation over it. Same for encryption, there are already existing crypto layers both on the block and filesystem (as an overlay) level.

I think to even call volume management a "layer" as though traditional storage was designed from first principles, is a mistake. Volume management is a just a hack. We had all of these single-disk filesystems, but single disks were too small. So volume management was invented to present the illusion (in other words, lie) that they were still on single disks. If you replace "disk" with "DIMM", it's immediately obvious…

Indeed there is no volume management for RAM. You have to reboot to rebuild the memory layout! RAM is higher in the caching hierarchy and can be rebuilt at smaller cost. You can't resize RAM while keeping data because nobody bothered to introduce volume management for RAM.

Storage is at the bottom of the caching hierarchy where people get inventive to avoid rebuilding. Rebuilding would be really costly there. Hence we use volume management to spare us the cost of rebuilding.

RAM also tends to have uniform performance. Which is not true for disk storage. So while you don't usually want to control data placement in RAM, you very much want to control what data goes on what disk. So the analogy confuses concepts rather than illuminating commonalities.

Re: Linus: Don't Use ZFS

#483

Post by rbanffy »

starfallg wrote: post #123
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?

Btrfs is the only FS I used that resulted in complete FS corruption losing nearly all data on disk, not once, but 3 times. After that, none of the features like compression, snapshots, COW or checksums meant anything to me. I'm much happier with ext4 and xfs on lvm.

Anecdote, I know, but I have about a dozen machines with BtrFS volumes, all active with varying loads and never experienced data loss. It seems some features are more mature than others - only two of the volumes span more than one disk and none has files that are larger than a physical volume (even though one of the multi-device volumes is striped).

Re: Linus: Don't Use ZFS

#485

Post by colonwqbang »

sandov wrote: post #225
gh123man wrote: post #77

Earlier quoted context omitted.

I am also not an expert in this space - but if I understand correctly the reason the linux Nvidia driver sucks so much is that it is not GPL'd (or open source at all). There is little incentive for Nvidia to maintain a linux specific driver, but because it is closed source the community cannot improve/fix it. > Why are all drivers expected to use the GPL? I think the answer to this is: drivers are expect to use the G…

> 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 don't care about this Jesus stuff but can I have some free wine and cookies please".

Full disclosure my day job is to write out of tree drivers for Linux :)

Re: Linus: Don't Use ZFS

#486

Post by cycloptic »

Wowfunhappy wrote: post #458
mikekchar wrote: post #333

Earlier quoted context omitted.

> Linux is able to run proprietary userspace software. Even most open source zealots agree that this is necessary. Why are all drivers expected to use the GPL? To answer your excellent question (and ignore the somewhat unfortunate slam on people who seem to differ with your way of thinking), it is an intentional goal of software freedom. The idea of a free software license is to allow people to obtain a license to th…

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 through a manual approval process. And don't forget iOS, which doesn't even support user-loadable drivers at all.

>Should the currently-in-development Windows ZFS port reach maturity and gain widespread adoption (which feels possible!), do you foresee a possibility of Oracle suing? If not, why is Linux different?

I'm not sure, I haven't used Windows in many years and I don't know their policies. But see what I said earlier: the simple answer is that the license is different from the license of Linux. For more details, the question you should be asking is: Is the CDDL incompatible with Windows licensing?

Re: Linus: Don't Use ZFS

#487

Post by Dylan16807 »

vetinari wrote: post #427
Dylan16807 wrote: post #228

Earlier quoted context omitted.

But from what I can see, marking the "save SIMD registers" function as GPL is a blatant lie by a kernel developer that wanted to spite certain modules. Saving and restoring registers is an astoundingly generic function. If you list all the kernel exports and sort by how much they make your work derivative, it should be near the very bottom.

You are not supposed to use FP/SSE in kernel mode. It was always frowned upon: > In other words: it's still very much a special case, and if the question was "can I just use FP in the kernel" then the answer is still a resounding NO, since other architectures may not support it AT ALL. > Linus Torvalds, 2003 and these specific functions, that were marked as GPL were already deprecated for well over a decade.

> You are not supposed to use FP/SSE in kernel mode.

> It was always frowned upon

Whether it's frowned upon is a completely different issue from whether it intertwines your data so deeply with the kernel that it makes your code a derivative work subject to the GPL license. Which it doesn't.

> if the question was "can I just use FP in the kernel" then the answer is still a resounding NO, since other architectures may not support it AT ALL.

It's not actually using floating point, it's using faster instructions for integer math, and it has a perfectly viable fallback for architectures that don't have those instructions. But why use the slower version when there's no real reason to?

> and these specific functions, that were marked as GPL were already deprecated for well over a decade.

But the GPL export is still there, isn't it? It's not that functionality is being removed, it's that functionality is being shifted to only have a GPL export with no license-based justification for doing so.

Re: Linus: Don't Use ZFS

#488

Post by vetinari »

shawnz wrote: post #467
vetinari wrote: post #427

Earlier quoted context omitted.

You are not supposed to use FP/SSE in kernel mode. It was always frowned upon: > In other words: it's still very much a special case, and if the question was "can I just use FP in the kernel" then the answer is still a resounding NO, since other architectures may not support it AT ALL. > Linus Torvalds, 2003 and these specific functions, that were marked as GPL were already deprecated for well over a decade.

So what meets the criteria of being a "special case" and what doesn't? One of the examples that Linus gives is RAID checksumming. How come RAID checksumming is a special case but ZFS checksumming isn't? I don't think it has anything to do with the nature of the usage, the only problem is that the user is ZFS.

RAID checksuming is in the kernel, and when Linus says jump, the RAID folks ask back how high.

He is not going to beg people outside kernel, whether he is allowed to change something that may break their module. On the contrary, they must live with any breackage that is thrown at them.

Again, that symbol was deprecated for well over a decade. How long does it take to be allowed to remove it?

Re: Linus: Don't Use ZFS

#489

Post by vetinari »

AnIdiotOnTheNet wrote: post #455
vetinari wrote: post #438

Earlier quoted context omitted.

Depends also on the AMD GPU. Vega is fine, Raven Ridge had weird bugs last time I looked, with rx590 I couldn't even boot the proxmox 6.1 installer (it worked when I swapped in rx580 instead). Why is Intel not a competition? In laptops, I want only Intel, nothing else. It is the smoothest/most reliable/least buggy thing you may have.

Performance wise, Intel is streets behind.

I know. But do you need that performance for what you do on the computer?

For most uses, Intel GPU is fine.

Re: Linus: Don't Use ZFS

#490

Post by anoncake »

vetinari wrote: post #489
AnIdiotOnTheNet wrote: post #455

Earlier quoted context omitted.

Performance wise, Intel is streets behind.

I know. But do you need that performance for what you do on the computer? For most uses, Intel GPU is fine.

But if you do need that performance, Intel isn't an option. If you don't, there is no reason to even consider Nvidia. They serve different needs.
Post reply on HN