Linus: Don't Use ZFS • Hacker News Board

Re: Linus: Don't Use ZFS

#251

Post by barrkel » Fri, Jan 10, 2020, 1:53 AM UTC

zelly wrote: post #138

He's not wrong. ext4 is actually maintained. This matters. ZFS hasn't kept up with SSDs. ZFS partitions are also almost impossible to resize, which is a huge deal in today's world of virtualized hardware. Honestly Linus's attitude is refreshing. It's a sign that Linux hasn't yet become some stiff design-by-committee thing. One guy ranting still calls the shots. I love it. Protect this man at all costs.

He is wrong. He's focused on performance; people use ZFS for its features, not its performance.

Re: Linus: Don't Use ZFS

#252

Post by m4rtink » Fri, Jan 10, 2020, 1:55 AM UTC

zlynx wrote: post #207

m4rtink wrote: post #190

Earlier quoted context omitted.

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

My terrible experiences with thin pools makes me see btrfs as a pool of wonderful, trouble-free and perfect code. Just ask yourself what happens when a thin pool runs out of actual, physical disk blocks?

Isn't this a problem for any over provisioned storage pool ? You can avoid that if you want by not over provisioning & checking space consumed by CoW snapshots. Also what does ZFS do if you run out of blocks ?

I have actually managed to run out of blocks on XFS on thin LV and it's an interesting experience. XFS always survoved just fine, but some files basically vanished. Looks like mostly those that were open and being written to at exhaustion time, like for example a mariadb database backing store. Files that were just sitting there were perfectly fine as far as I could tell.

Still, you definitely should never put data on a volume where a pool can be exhausted, without a backup as I don't think there is really a bulletproof way for a filesystem to handle that happening suddenly.

Re: Linus: Don't Use ZFS

#253

Post by m4rtink » Fri, Jan 10, 2020, 1:59 AM UTC

esoterae wrote: post #161

wazoox wrote: post #130

Earlier quoted context omitted.

ZFS performs quite well if you give it boatloads of RAM. It uses its own cache layer, and eats RAM like hotcakes. XFS OTOH is as fast as the hardware can go with any amount of RAM.

Sort of. But no snapshots. Wanna use LVM for snapshots? 33% performance hit for the entire LV per snapshot, by implementation. ZFS? ~1% hit. I've never been able to see any difference at the workloads I run, whereas with LVM it was pervasive and inescapable.

That's for the old "fat" LVM snapshots, right ? No way the new CoW thin LVs have such a big overhead for snapshots.

Re: Linus: Don't Use ZFS

#254

Post by rossdavidh » Fri, Jan 10, 2020, 2:02 AM UTC

geoff-dot wrote: post #248

Are there any lawyers that can verify the legal claims made? Anyone can file a lawsuit at anytime for whatever reason, that doesn't mean the lawsuit is valid. Sure using ZFS on your home system or even a small implementation is not a big deal but if there's a company with money lawsuits happen. I would think the wide availability and usage of ZFS and the fact that this is no longer 20 years ago when companies would s…

To be honest, given Oracle's history, I'm not sure I would even trust a lawyer's opinion, since it could still cost you a lot of money to defend against an Oracle lawsuit even if you win.

Re: Linus: Don't Use ZFS

#255

Post by barrkel » Fri, Jan 10, 2020, 2:02 AM UTC

maximente wrote: post #58

i wouldn't use ZFS either. my guess is 90% of ZFS users have never run failure scenarios and grappled with potential failure modes of ZFS, nor even know that you really need ECC RAM to run ZFS without fear of existential data corruption due to bit flips. furthermore, the allure of ZFS means people aren't testing their disaster plans until it's too late, bc ZFS is "resilient". lastly, data recovery is expensive as all…

ZFS has seen me through 6 disk failures since I started using it on Nexenta about 10 years ago; zero data loss.

It's not a backup by itself, but it makes a fine backup target if it's located somewhere else, since it's both redundant (hard to lose data by accident) and snapshotted (hard to lose data by mistake) - it was my local CrashPlan target (alongside cloud) back when CrashPlan supported home users.

Re: Linus: Don't Use ZFS

#256

Post by shmerl » Fri, Jan 10, 2020, 2:06 AM UTC

I hope bcachefs will get to usable state soon.

Re: Linus: Don't Use ZFS

#257

Post by shmerl » Fri, Jan 10, 2020, 2:06 AM UTC

yjftsjthsd-h wrote: post #23

Alright, Linus, I'll make you a deal: I'll consider dropping ZFS when you ship a production-grade BTRFS (or reiserfs or anything else with the same features).

bcachefs is aiming to replace btrfs.

Re: Linus: Don't Use ZFS

#258

Post by m4rtink » Fri, Jan 10, 2020, 2:11 AM UTC

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.

All this is functionality tested by years of production use.

For compression/deduplication, that is AFAIK work in progress upstream based on the open sourced VDO code.

Re: Linus: Don't Use ZFS

#259

Post by m4rtink » Fri, Jan 10, 2020, 2:17 AM UTC

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.

XFS on LVM thin pool thin LV gives you fas CoW snapshots and is rock solid. Really, try it. :)

Re: Linus: Don't Use ZFS

#260

Post by DoofusOfDeath » Fri, Jan 10, 2020, 2:18 AM UTC

Polylactic_acid wrote: post #246

smileybarry wrote: post #172

Earlier quoted context omitted.

IIRC VirtualBox offers to download the Extension Pack without stating it's not free for commercial use. There isn't even a link to the EULA in the download dialog as far as I can tell (from Google Images, at least). Conversely, VirtualBox itself is free for commercial use. Feels more like a honeypot than license auditing. They can also apply stronger heuristics, like popping up a dialogue box if the computer is centr…

Wait is this the pack that gets screen resizing and copy/paste working?

A tad offtopic, but on my 2017 Macbook Pro the "pack" was called VMWare Fusion.

With my MBP as host and Ubuntu as guest, I found that VirtualBox (with and without guest extensions installed) had a lot of graphical performance issues that Fusion did not.