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

271–280 of 571 posts

Re: Linus: Don't Use ZFS

#271

Post by muxator »

berbec wrote: post #120
dsr_ wrote: post #51

Earlier quoted context omitted.

On the surface, btrfs is pretty close to zfs. Once you actually use them, you discover all the ways that btrfs is a pain and zfs is a (minor) joy: - snapshot management - online scrub - data integrity - disk management I lost data from perfectly healthy-appearing btrfs systems twice. I've never lost data on maintained zfs systems, and I now trust a lot more data to zfs than I ever have to btrfs.

The one thing I can't understand about btrfs is the unknown answer to the question "How much disk space do I have left?". I don't get that being a "this much, maybe" answer

# btrfs filesystem usage /

Overall:

    Device size:         142.86GiB
    Device allocated:     48.05GiB
    Device unallocated:   94.81GiB
    Device missing:          0.00B
    Used:                 37.75GiB
    Free (estimated):    103.94GiB  (min: 103.94GiB)
    Data ratio:               1.00
    Metadata ratio:           1.00
    Global reserve:       82.20MiB  (used: 0.00B)

Re: Linus: Don't Use ZFS

#272

Post by [deleted] »

djsumdog wrote: post #11
Hamuko wrote: post #7

Earlier quoted context omitted.

That's his reasoning for not merging ZFS code, not for generally avoiding ZFS.

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.

[deleted]

Re: Linus: Don't Use ZFS

#273

Post by reacharavindh »

m4rtink wrote: post #258
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.

XFS on LVM thin pool LV should give you a very robust fs, cheap CoW snapshots, multi device support. If you want, you can make the thin pool be on RAID via LVM RAID under the thin pool. For import export, IIRC XFS has support for it and you can dump/import LV snapshots to get atomicity. For caching there is LVM cache, should be again possible to combine with thinpool & RAID. Or you can use it separately for normal LV…

Interesting combination of tools I have used independently but never as a replacement of my beloved ZFS.

Never made snapshots with LVM. Always used LVM as a way to carve up logical storage from a pool of physical devices but nothing more. I need to RTFM on how snapshotting would work there - could I restore just a few files from an hour ago while letting everything else be as they are?

With ZFS, I use RAM as read chace(ARC) and an Optane disk as sync write cache(SLOG). I wonder if LVM cache would let me do such a thing. Again, a pointer for more manual reading for me.

Compression is a nice to have for me at this moment. Good to know that it is being worked on at the LVM layer.

Re: Linus: Don't Use ZFS

#274

Post by jordanbeiber »

HorstG wrote: post #107
montjoy wrote: post #81

Earlier quoted context omitted.

Last time I used ZFS write performance was terrible compared to an ordinary RAID5. IIRC Writes in a raidz are always limited to a single disk’s performance. The only way to get better write speed is to combine multiple raidzs - which means you need a boatload if disks.

We had a bunch of Thumpers (SunFire X4200) with 48 disks at work, running ZFS on Solaris. It was dog slow and awful, tuning performance was complicated and took ages. One had to use just the right disks in just the right order in RaidZs with striping over them. Swap in a hotspare: things slow to a crawl (i.e. not even Gbit/s). After EoL a colleague installed Linux with dmraid, LVM and xfs on the same hardware: much f…

ZFS, on Solaris, not robust?

ZFS for “play”?!

This... is just plain uninformed.

Not just me and my employer, but many (many) others rely on ZFS for critical production storage, and have done so for many years.

It’s actually very robust on Linux as well - considering the fact that freeBSD have started to use the ZoL code base is quite telling.

Would freeBSD also be in the “play” and “not robust” category as well, hanging out together with Solaris?

Will it perform better than all in terms of writes/s? Most likely not - although by staying away from de-dup, enough RAM and adhere the pretty much general recommendation to use mirror vdevs only in your pools, it can be competitive.

Something solid with data integrity guarantees? You can’t beat ZFS, imo.

Re: Linus: Don't Use ZFS

#275

Post by bigiain »

btilly wrote: post #35
Hamuko wrote: post #7

Earlier quoted context omitted.

That's his reasoning for not merging ZFS code, not for generally avoiding ZFS.

Here are his reasons for generally avoiding ZFS from what I consider most important to least. - The kernel team may break it at any time, and won't care if they do. - It doesn't seem to be well-maintained. - Performance is not that great compared to the alternatives. - Using it opens you up to the threat of lawsuits from Oracle. Given history, this is a real threat. (This is one that should be high for Linus but not…

> there is no conceivable reason that Oracle would want to threaten me with a lawsuit.

Money. Anecdotally that's the primary reason Oracle do anything.

Re: Linus: Don't Use ZFS

#276

Post by crashbunny »

supercanuck wrote: post #195
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.

Oracle sued Google for copying the same names of the functions.

And I believe oracle copied the amazon s3 api.

I can't make a informed opinion but my uninformed gut feeling is oracle have done what they are suing google for having done.

Re: Linus: Don't Use ZFS

#277

Post by admax88q »

cookiecaper wrote: post #268
liuliu wrote: post #166

Earlier quoted context omitted.

bcachefs should be heavily supported, it doesn't get nearly enough for what it supposes to do: https://www.patreon.com/bcachefs

Honestly just use ZFS. We've wasted enough effort over obscure licensing minutia.

> We've wasted enough effort over obscure licensing minutia.

Which was precisely Sun/Oracle's goal when they released ZFS under the purposefully GPL incompatible CDDL. Sun was hoping to make OpenSolaris the next Linux whilst ensuring that no code from OpenSolaris could be moved back to linux. I can't think of another plausible reason why they would write a new open source license for their open source operating system and making such a license incompatible with the GPL.

Re: Linus: Don't Use ZFS

#278

Post by ttttttttttt- »

Wowfunhappy wrote: post #70
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…

> And I'm not at all interested in some "ZFS shim layer" thing either If there is no "approved" method for creating Linux drivers under licenses other than the GPL, that seems like a major problem that Linux should be working to address. Expecting all Linux drivers to be GPL-licensed is unrealistic and just leads to crappy user experiences. nVidia is never going to release full-featured GPL'd drivers, and even corpor…

>If there is no "approved" method for creating Linux drivers under licenses other than the GPL, that seems like a major problem that Linux should be working to address.

As a Linux user and an ex android user, I absolutely disagree and would add that the GPL requirement for drivers is probably the biggest feature Linux has!

Re: Linus: Don't Use ZFS

#279

Post by 0x8BADF00D »

wahern wrote: post #198
0x8BADF00D wrote: post #86

Honestly ext4 is fine for most use cases, even SSDs. If you really need more performance look at HAMMER, it’s meant for high availability. At that point you shouldn’t be running Linux anyway, even with RT_PREEMPT it’s not going to be the most performant for those kinds of RTOS workloads anyway.

HAMMER2 is now the default on DragonflyBSD. If I made a bunch of money during the boom and could spend my days doing open source (like Matt Dillon), porting HAMMER2 might be one of the projects I'd pick up.

That would be a neat project. It’s hard to set aside the time when you don’t have much in the time bank. I’ve been wanting to do a lot more research on kernel scheduling, writing my own alternative scheduler, and more research on RTOS design and real-time computing in general.

Re: Linus: Don't Use ZFS

#280

Post by barkingcat »

Linus is correct in his arguments. As the lead for the linux project, he shouldn't merge things that he feels isn't up to stuff from a license point of view.

That's why we have different software.

If you asked Theo to merge an encryption algorithm for example into OpenSSH and OpenBSD - he's going to have an opinion about it - and that's his thing.

Why would this be controversial at all?

Post reply on HN