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

421–430 of 571 posts

Re: Linus: Don't Use ZFS

#421

Post by vetinari »

School-Cotton wrote: post #289
talideon wrote: post #266

Earlier quoted context omitted.

My employer straight up banned the use of VirtualBox entirely _just in case_. They'd rather pay for VMWare Fusion licenses than deal with any potential crap from Oracle.

Anecdotal, but VirtualBox has always been a bit flaky for me. VMWare Fusion, on the other hand, powers the desktop environment I've used as a daily work machine for the last 6 months, and I've had absolutely zero problems other than trackpad scrolling getting emulated as mouse wheel events (making pixel-perfect scroll impossible). Despite that one annoyance, it's definitely worth paying for if you're using it for any…

On the other hand, VMWare Fusion kernel extension is the only culprit, why I've seen kernel panic on Mac.

Re: Linus: Don't Use ZFS

#422

Post by notacoward »

wheybags wrote: post #373
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.

Because the FS can be deeply integrated with the RAID implementation. With a normal RAID, if the data at some address is different between the two disks, there's no way for the fs to tell which is correct, because the RAID code essentially just picks one, it can't even see the other. With ZFS for example, there is a checksum stored with the data, so when you read, zfs will check the data on both and pick the correct…

> 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 select specific copies/shards and figure out which ones are good. I work on one of the four or five largest storage systems in the world, and have written code to do exactly this (except that it's Reed-Solomon rather than RAID). I've seen it detect and fix bad blocks, many times. It works, even with separate layers.

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. Understanding other complex subsystems is hard, and it's more fun to write new code instead.

Re: Linus: Don't Use ZFS

#424

Post by irenedowd »

Hi. I ran over a generally excellent Hacker Goatse Security. They have assisted with a ton of issues like Phone Hack, Account Hack, Clear Debts, Grade overhaul E.t.c

Contact: goatsesecure (at) gmail Text/Whatsapp: +1 646 389 4585

Re: Linus: Don't Use ZFS

#425

Post by Annatar »

HorstG wrote: post #385
Annatar wrote: post #371

Earlier quoted context omitted.

"After EoL a colleague installed Linux with dmraid, LVM and xfs on the same hardware: much faster, more robust." Please let me know which company this is, so I can ensure that I never end up working there by accident. Much obliged in advance, thank you kindly.

Why? What is bad about playing around with leftover hardware?

Nothing at all; it's what was done to that hardware that's the travesty here. It takes an extraordinary level of incompetence and ignorance to even get the idea to slap Linux with dmraid and LVM on that hardware and then claim that it was faster and more robust without understanding how unreliable and fragile that constelation is and that it was faster because all the reliability was gone.

Re: Linus: Don't Use ZFS

#426

Post by rhinoceraptor »

mschuster91 wrote: post #345
ac29 wrote: post #295

Earlier quoted context omitted.

Many of the advanced features aren't implemented yet though, like compression, encryption, snapshots, RAID5/6....

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 that volume management is ridiculous. When you add a DIMM to a machine, it just works. There's no volume management for DIMMs.

Re: Linus: Don't Use ZFS

#427

Post by vetinari »

Dylan16807 wrote: post #228
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

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.

Re: Linus: Don't Use ZFS

#428

Post by vetinari »

Annatar wrote: post #365
m4rtink wrote: post #190

Earlier quoted context omitted.

XFS on LVM thin pool LV. Stable and performant as far as I can tell.

XFS is not copy on write.

XFS has supported reflinks for some time already, just the deduplication is kind of experimental.

Supporting reflinks is actually more, than can be said about ZoL (see zfsonlinux#405).

Re: Linus: Don't Use ZFS

#429

Post by vetinari »

Covzire wrote: post #22
djsumdog wrote: post #11

Earlier quoted context omitted.

Well he had this: > as far as I can tell, it has no real maintenance behind it either any more Which simply isn't true. They just released a new ZFS version with encryption built in (no more ZFS + LUKS) and they removed the SPL dependency (which didn't support Linux 5.0+ anyway). I use ZFS on my Linux machines for my storage and I've been rather happy with it.

Same, for at least 6 years in a 4 drive zraid array. It always reads and writes at full gigabit ethernet speeds and I haven't had any downtime other than maintaining FreeBSD updates which are trivial even when going from 10.x to 11 to 12.

A single 5400 rpm drive (the like of wd red) should be able to saturate gigabit ethernet. 4 drive array should be basically idling.

Re: Linus: Don't Use ZFS

#430

Post by Nasrudith »

yjftsjthsd-h wrote: post #218
shawnz wrote: post #157

Earlier quoted context omitted.

> This being "Oracle," and its litigious nature, how can you truly be aware or sure? The functionality I'm describing has absolutely nothing to do with ZFS or Oracle in any way. If you really think the reach of Oracle is so great, then why not block all Oracle code from ever running on the OS? That seems to me to be just as justified as this change.

> why not block all Oracle code from ever running on the OS? ...to be fair, I would probably run that module.

I think that it would be a mandated module by many companies.
Post reply on HN