Oracle rears its head again lolz
Linus: Don't Use ZFS
351–360 of 571 posts
Re: Linus: Don't Use ZFS
#352Earlier quoted context omitted.
I'm baffled by such arguments. > It doesn't seem to be well-maintained. The last commit is from 3 hours ago: https://github.com/zfsonlinux/zfs/commits/master . They have dozens of commits per month. The last minor release, 0.8, brought significant improvements (my favorite: FS-level encryption). Or maybe this is referred to the 5.0 kernel (initial) incompatibility? That wasn't the ZFS dev team's fault. > Performance…
> There are no (stable) alternatives. BTRFS certainly not, as it's "under heavy development"¹ (since... forever). Unless you are living in 2012 on a RHEL/CENTOS 6/7 machine, btrfs has been stable for way too long. I have been using btrfs as the sole filesystem on my laptop in standard mode, on my desktop as RAID0 and my NAS as RAID1 for more that two years. I have experienced absolutely zero data loss. Infact, btrfs…
I also used btrfs not too long ago in RAID1. I had a disk failure and voila, the array would be read-only from now on and I would have to recreate it from scratch and copy data over. I even utilized the different data recovery methods (at some point the array would not be mountable no matter what) and in the end that resulted in around 5% of the data being corrupt. I won't rule out my own stupidity in the recovery steps, but after this and the two other times when my RAID1 array went read-only _again_ I just can't trust btrfs for anything other than single device DUP mode operation.
Meanwhile ZFS has survived disk failures, removing 2 disks from an 8 disk RAIDZ3 array and then putting them back, random SATA interface connection issues that were resolved by reseating the HDD, and will probably survive anything else that I throw at it.
Re: Linus: Don't Use ZFS
#353Earlier quoted context omitted.
But why are all drivers expected to be "part of the project"? We don't treat userspace Linux software that way. We don't consider Windows drivers part of Windows.
Because running proprietary binaries in kernel space is not a good idea nor is it compatible with the vision of Linux?
ZFS isn't proprietary it's merely incompatible with the gpl.
Re: Linus: Don't Use ZFS
#354Earlier quoted context omitted.
> 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-reading my comment in daylight I realize I got one detail almost exactly wrong: we were always <= 2 developers, but it seems everyone understood the point anyway - we were tiny, but not too tiny for Oracles licensing department.
Re: Linus: Don't Use ZFS
#355Earlier quoted context omitted.
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…
Call me when somebody like a major cloud provider has used this system to drive millions of hard-drives. I'm not gone patch my data security together like that. There is difference between 'all these tools have been used in production' and 'this is an integrated tool that has been used for 15+ years in the biggest storage installations in the world'.
Yes! The problem with the LVM approach trying to replicate anything ZFS is doing that you have to use a myriad of different tools. And then you have to pray that they all work correctly together, and if one has a bug you possible lost all your data because there may be so many data corruptions emerging because of it.
Re: Linus: Don't Use ZFS
#356I'll give up Linux on my servers before I give up ZFS especially so given the recent petulant attitude that broke API compatibility in the LTS branch just to spite the ZFS developers: https://news.ycombinator.com/item?id=20186458 compete honestly on technical merit, rather than pulling dirty tricks that you'd expect of Oracle or 1990's MS
The core development team hasn't really been fully trustworthy since they spent years pretending their cpu scheduler wasn't hot garbage for desktop usage, denied the need for a pluggable scheduler to allow multiple schedulers to be selected from, then seemingly an age later implemented something in the same vein as CK while giving zero credit.
Re: Linus: Don't Use ZFS
#357Yes, don't use ZFS! Use FreeBSD and ZFS!
Re: Linus: Don't Use ZFS
#358Earlier 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…
>- 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 for me - there is no conceivable reason that Oracle would want to threaten me with a lawsuit.)
No. Distributing (ie. precompiled distro with ZFS) will. You are free to run any software on your machine as you so desire.
Re: Linus: Don't Use ZFS
#359Earlier 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
I've been looking forward to using bcachefs as I had a few bad experiences with btrfs. Is bcachefs more-or-less ready for some use cases now? Does it still support caching layers like bcache did?
It's quite usable, but of course, do not trust it with your unique unbacked-up data yet.
I use it as a main FS for a desktop workstation and I'm pretty happy with it. Waiting impatiently for EC to be implemented for efficient pooling of multiple devices.
Regarding caching: "Bcachefs allows you to specify disks (or groups thereof) to be used for three categories of I/O: foreground, background, and promote. Foreground devices accept writes, whose data is copied to background devices asynchronously, and the hot subset of which is copied to the promote devices for performance."
Re: Linus: Don't Use ZFS
#360Nicely written Linus, very soft and considerate of other's feelings. Not so funny anymore but overall it will make more people happy :)