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

281–290 of 571 posts

Re: Linus: Don't Use ZFS

#281

Post by barkingcat »

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."

Don't be so sure about this.

Re: Linus: Don't Use ZFS

#282

Post by eitland »

bigiain wrote: post #275
btilly wrote: post #35

Earlier quoted context omitted.

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.

If anyone thinks this is hyperbole :

I worked for a tiny startup (>2 devs full time) where Oracle tried to extract money from us because we used MariaDB on AWS.

If you think this sounds ridiculous you probably got it right.

(Why? Because someone inexperienced with Oracle had filled out the form while downloading the mySQL client.)

Re: Linus: Don't Use ZFS

#283

Post by damm »

His reasons may not be perfect but he's right.

If you use a filesystem that isn't mainline and it breaks it's all on you to figure it out and fix it. Having used experimental filesystems before and been burned I would rather stick with what I know and won't change overnight.

I'll keep an eye open for new filesystems of course but if it's not mainline unless it's for personal hacking no.

> I own several SBC's (Small Board Computer) that do not run mainline kernels. The company that makes them provides their own patched kernel so if it breaks I'm up creek but I know who to bitch at.

Re: Linus: Don't Use ZFS

#284

Post by dathinab »

ploxiln wrote: post #171
Hamuko wrote: post #7

Earlier quoted context omitted.

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

It's exactly that, when combined with the longstanding practice of maintaining compatibility with userspace, but reserving the right to refactor kernel-space code whenever and wherever needed. If ZFS-on-linux breaks in a subtle or obvious way due to a change in linux, he can't afford to care about that - keeping the linux kernel codebase sane while adding new features, supported hardware, optimizations, and fixes at…

> he can't afford to care about that - keeping the linux kernel codebase sane while adding new features, supported hardware, optimizations, and fixes at an honestly scary rate, is not that easy.

Maybe, but the complains seem to be more related to the (problematic) changes not being of technical nature accidentally braking ZFS, but being more of political nature. With speculation that it might have been meant to _intentionally_ brake ZFS and then pretend this was a accident because ZFS isn't (and can never) be maintained in tree. Basically on the line of "we don't like out of tree kernel modules so we make the live hard for them". No idea if this is actually the case or people just spin thinks together. Even if it is the case I'm not sure what I should think about, because it's at least partially somewhat understandably.

Re: Linus: Don't Use ZFS

#285

Post by sterlind »

celticmusic wrote: post #177
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…

My experience is that linux nvidia drivers are better than the competitors open source drivers.

Nvidia proprietary drivers work OK for me, mostly (I needed to spoof the video card ID so KVM could lie to the Windows drivers in my home VFIO setup, but it wasn't hard.)

But it means I can't use Wayland. Wayland isn't critical for me, but since NVidia is refusing to implement GBM and using EGLStream instead, there's nothing I can do about it. It simply isn't worth NVidia's time to make Wayland work, so I'm stuck using X. If the driver were open-source someone would have submitted a GBM patch and i wouldn't be stuck in this predicament.

I can't wait for NVidia to have real competition in the ML space so I can ditch them.

Re: Linus: Don't Use ZFS

#286

Post by awused »

m4rtink wrote: post #252
zlynx wrote: post #207

Earlier quoted context omitted.

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 be…

>Isn't this a problem for any over provisioned storage pool ?

ZFS doesn't over-provision anything by default. The only case I'm aware of where you can over-provision with ZFS is when you explicitly choose to thin provision zvols (virtual block devices with a fixed size). This can't be done with regular file systems which grow as needed, though you can reserve space for them.

File systems do handle running out of space (for a loose definition of handle) but they never expect the underlying block device to run out of space, which is what happens with over-provisioning. That's a problem common to any volume manager that allows you to over provision.

Re: Linus: Don't Use ZFS

#287

Post by sterlind »

RussianCow wrote: post #104
puzzledobserver wrote: post #100

Earlier quoted context omitted.

I would expect a large fraction of Nvidia's GPU sales to be from customers wanting to do machine learning. What platform do these customers typically use? Windows? How do the Linux and Windows drivers compare on matters related to CUDA?

Nvidia has a proprietary Linux driver that works just fine for GPGPU purposes. But because it's not GPLed, it will never be mainlined into the kernel, so you have to install it separately. This is in contrast to AMD GPUs, for which the driver lives in the Linux kernel itself.

Critically, Nvidia has a GPL'd shim. In the kernel code, which lets them keep a stable ABI. The kind of shim Linus isn't interested in for ZFS.

Re: Linus: Don't Use ZFS

#288

Post by metaphor »

berti wrote: post #230
HorstG wrote: post #206

Earlier quoted context omitted.

Some features such as Raid5 were still firmly in "don't use if you value your data" territory last I looked. So it is important to be informed as to what can be used and what might be more dangerous with btrfs

Keep in mind that RAID5 isn’t feasible with multi-TB disks (the probability of failed blocks when rebuilding the array is far too high). That said, RAID6 also suffers the same write-hole problem with Btrfs. Personally I choose RAIDZ2 instead.

To be sure, it's entirely feasible, just not prudent with today's typical disk capacities.

Re: Linus: Don't Use ZFS

#289

Post by School-Cotton »

talideon wrote: post #266
organsnyder wrote: post #88

Earlier quoted context omitted.

A former employer was threatened by Oracle because some downloads for the (only free for noncommercial use) VirtualBox Extension Pack came from an IP block owned by the organization. Home users are probably safe, but Oracle's harassment engine has incredible reach.

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 serious or professional purpose.

Re: Linus: Don't Use ZFS

#290

Post by ilikejam »

admax88q wrote: post #277
cookiecaper wrote: post #268

Earlier quoted context omitted.

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 syste…

There were genuine reasons for the CDDL - it wasn't an anti-gpl thing. https://www.youtube.com/watch?v=-zRN7XLCRhc&feature=youtu.be...
Post reply on HN