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

561–570 of 571 posts

Re: Linus: Don't Use ZFS

#561

Post by MaxBarraclough »

fierarul wrote: post #552
MaxBarraclough wrote: post #509

Earlier quoted context omitted.

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.

Well, depends what you mean by solid legal ground then. Nobody is / should be seriously concerned by using the open source OpenZFS modules with their Linux distro of choice.

> depends what you mean by solid legal ground then

I'm referring to having confidence that using OpenJDK, in the absence of any licensing agreement with Oracle, will not land your company in legal trouble.

I'm not seeing an ambiguity in my use of solid legal ground.

> Nobody is / should be seriously concerned by using the open source OpenZFS modules with their Linux distro of choice.

Linus isn't convinced that it's legally safe to do this, and neither are some people in this thread, myself included.

It may be true that even Oracle are unlikely to go after you for using ZFS from Linux, but if it's not safe enough for Linus, it's probably not safe enough for the legal departments of large companies.

Re: Linus: Don't Use ZFS

#562

Post by snvzz »

denimboy wrote: post #203
esoterae wrote: post #161

Earlier quoted context omitted.

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.

I don't doubt this but do you have any documentation? Asking for a friend who uses XFS on LVM for disk heavy applications like database, file server, etc.

FreeNAS has good documentation on which hardware to pick and how to set up ZFS.

Re: Linus: Don't Use ZFS

#564

Post by ColanR »

Dylan16807 wrote: post #557
macdice wrote: post #556

Earlier quoted context omitted.

Care to elaborate?

You can't make a copy-on-write copy of a file. You can't deduplicate existing files, or existing snapshots. You can't defragment. You can't remove devices from a pool. That last one is likely to get some kind of hacky workaround. But nobody wants to do the invasive changes necessary for actual BPR to enable that entire list.

Wow. As a casual user - someone who at one point was trying to choose between RAID, LVM and ZFS for an old NAS - some of those limitations of ZFS seem pretty basic. I would have taken it for granted that I could remove a device from a pool or defragment.

Re: Linus: Don't Use ZFS

#565

Post by berbec »

muxator wrote: post #271
berbec wrote: post #120

Earlier quoted context omitted.

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)

"Free (estimated)"

Re: Linus: Don't Use ZFS

#566

Post by phyzome »

alperakgun wrote: post #145
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.

in the application-level, snapshotting is not a way to do "consistent backup"s . consistent backup is a backup with a planned or known state when "restore"ing.

I can't do anything about partial file writes in the general case, but it's close enough—and any ACID databases should be able to restore from such a snapshot.

Re: Linus: Don't Use ZFS

#567

Post by phyzome »

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

I don't remember the details, but when I looked into switching to LVM snapshots, I ran into some sort of blocker.

My use-case is that I run Sandstorm, and want to be able to back it up while it's running. That means:

  - Ensure there aren't any existing snapshots
  - Take a snapshot
  - Mount the snapshot as a filesystem
  - Run tarsnap against that filesystem
  - Release the snapshot
I think the trouble I ran into was at the mount step.

Re: Linus: Don't Use ZFS

#568

Post by talideon »

pizza234 wrote: post #392
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.

This is throwing the baby along with the bathwater. VirtualBox itself is GPL. There is no lawsuit risk. What requires "commercial considerations" is the extension pack. The extension pack is required for: > USB 2.0 and USB 3.0 devices, VirtualBox RDP, disk encryption, NVMe and PXE boot for Intel cards If licensing needs to be considered (ie. in a corporate environment), but one doesn't need the functionalities above,…

> This is throwing the baby along with the bathwater.

It might be, but let's just say that Oracle aren't big fans of $WORK, and our founders are big fans of them. Thus our legal department are rather tetchy about anything that could give them even the slightest chance of doing anything.

> What requires "commercial considerations" is the extension pack.

And our legal department are nervous about that being installed, even by accident, so they prefer to minimise the possibility.

Re: Linus: Don't Use ZFS

#569

Post by dekhn »

rleigh wrote: post #544
dekhn wrote: post #529

Earlier quoted context omitted.

I think you misunderstand: file deletions are what is slow (I don't use ZFS, my reference is WAFL, but my understanding is that all snapshotting file systems have this problem).

Even this should have minimal overhead. If the file is present in the snapshot, then it's simply moving the blocks over to the deadlist which is a very cheap operation. If it's not in the snapshot then the blocks will get recycled in the background. In both cases you should have the unlink complete almost immediately. All of the snapshot functionality is based upon simple transaction number comparisons plus the deadl…

I've been promised many things by vendors and they always fall back to "hey! look! cool CS file system theory". I test my systems carefully and report the results back; they often don't agree.

I should point out again that I don't have enough direct experience with ZFS to say if this is the case, my experience was with an enterprise NetApp server at a large company that was filling the disk up (>95%) in addition to doing hourly snapshots.

Re: Linus: Don't Use ZFS

#570

Post by montjoy »

jordanbeiber wrote: post #274
HorstG wrote: post #107

Earlier quoted context omitted.

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, hang…

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

This reminds me. We had one file server used mostly for package installs that used ZFS for storage. One day our java package stops installing. The package had become corrupt. So I force a manual ZFS scrub. No dice. Ok fine I’ll just replace the package. It seems to work but the next day it’s corrupt again. Weird. Ok I’ll download the package directly from Oracle again. The next day again it’s corrupt. I download a slightly different version. No problems. I grab the previous problematic package and put it in a different directory (with no other copies on the file system) - again it becomes corrupt.

There was something specific about the java package that ZFS just thought it needed to “fix”. If I had to guess it was getting the file hash confused. I’m pretty sure we had dedupe turned on so that may have factored into it.

Anyway that’s the first and only time I’ve seen a file system munge up a regular file for no reason - and it was on ZFS.

Post reply on HN