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

531–540 of 571 posts

Re: Linus: Don't Use ZFS

#531

Post by mekster »

throw0101a wrote: post #9
gigatexal wrote: post #5

He mentioned that he didn’t think it was being maintained. It’s more or less been formed no? Has Linus not seen the work that the OpenZFS folks are doing? ZFS is amazing and I would soon go to a BSD flavor with a fun set of user land utilities than give it up.

> He mentioned that he didn’t think it was being maintained. This news would come as a surprise to the folks at LLNL who work on ZoL: * https://github.com/zfsonlinux/zfs * https://zfsonlinux.org/

Maybe meant not maintained by the first party?

Re: Linus: Don't Use ZFS

#532

Post by DSMan195276 »

AnIdiotOnTheNet wrote: post #462
usefulcat wrote: post #128

Earlier quoted context omitted.

> With that, they do expose a userspace filesystem driver interface, FUSE. Yes, which Linus has also poo-pooed: "People who think that userspace filesystems are realistic for anything but toys are just misguided."

And yet people use them all the damn time because they're incredibly useful and even more importantly are relatively easy to put together compared to kernel modules. Linus is just plain wrong on this one.

You should read the full quote, he really doesn't disagree with you:

> fuse works fine if the thing being exported is some random low-use interface to a fundamentally slow device. But for something like your root filesystem? Nope. Not going to happen.

His point is that FUSE is useful and fine for things that aren't performance critical, but it's fundamentally too slow for cases where performance is relevant.

Re: Linus: Don't Use ZFS

#533

Post by kalleboo »

vetinari wrote: post #419
kalleboo wrote: post #267

Earlier quoted context omitted.

It's also the default file system of millions of Synology NASes running in consumer hands (although Synology shimmed on their own RAID5/6 support)

Synology uses standard linux md (for btrfs too). Even SHR (Synology Hybrid RAID) is just different partitions on the drive allocated to different volumes, so you can use mixed-capacity drives effectively.

Right, instead of BTRFS RAID5/6, they use Linux md raid, but I believe they have custom patches to BTRFS to "punch through" information from md, so that when BTRFS has a checksum mismatch it can use the md raid mirror disk for repair.

Re: Linus: Don't Use ZFS

#534

Post by montjoy »

ggm wrote: post #241
montjoy wrote: post #83

Earlier quoted context omitted.

Hardware RAID controllers can do most if not all of these things.

I've lost more data in hardware RAID than in ZFS but I have lost data in both. Hardware RAID has very poor longevity. Vendor support and battery backup replacement collide in BIOS and host management badly. Disclaimer: I work on Dell rackmounts, which means rather than native SAS I am 'Dells hack on SAS' which is a problem and I know its possible to 'downgrade' back to native.

Yeah we started ordering the ones with the supercap so we didn’t have to replace batteries anymore.

Somewhat recently I dealt with LSI and Dell cards. Longevity seemed just fine for a normal 3 year server lifecycle. The only time we had an issue is when the power went down in the data center. The power spike fried a few of the cards. Luckily we had spares.

Way way back I dealt with the Compaq/hp smartarrays. Those were awful. Also anything consumer grade is awful.

Re: Linus: Don't Use ZFS

#535

Post by throw0101a »

notacoward wrote: post #510
throw0101a wrote: post #469

Earlier quoted context omitted.

> This supposed need for ZFS to absorb all RAID/LVM/page-cache behavior into itself is a myth; what really happened is good old-fashioned NIH. At the time that ZFS was written (early 2000s) and released to the public (2006), this was not a thing and the idea was somewhat novel / 'controversial'. Jeff Bonwick, ZFS co-creator, lays out their thinking: * https://blogs.oracle.com/bonwick/rampant-layering-violation Rememb…

I debated some of this with Bonwick (and Cantrill who really had no business being involved but he's pernicious that way) at the time. That blog post is, frankly, a bit misleading. The storage "stack" isn't really a stack. It's a DAG. Multiple kinds of devices, multiple filesystems plus raw block users (yes they still exist and sometimes even have reason to), multiple kinds of functionality in between. An LVM API all…

> ... but in the broader world where multiple options are available at every level it's still bad engineering.

When Sun added ZFS to Solaris, they did not get rid of UFS and/or SVM, nor prevent Veritas from being installed. When FreeBSD added ZFS, they did not get rid of UFS or GEOM either.

If an admin wanted or wants (or needs) to use the 'old' way of doing things they can.

Re: Linus: Don't Use ZFS

#536

Post by throw0101a »

mekster wrote: post #531
throw0101a wrote: post #9

Earlier quoted context omitted.

> He mentioned that he didn’t think it was being maintained. This news would come as a surprise to the folks at LLNL who work on ZoL: * https://github.com/zfsonlinux/zfs * https://zfsonlinux.org/

Maybe meant not maintained by the first party?

ZoL is now the first-party for open sourced ZFS.

Re: Linus: Don't Use ZFS

#537

Post by starfallg »

microtonal wrote: post #457
starfallg wrote: post #123

Earlier quoted context omitted.

Btrfs is the only FS I used that resulted in complete FS corruption losing nearly all data on disk, not once, but 3 times. After that, none of the features like compression, snapshots, COW or checksums meant anything to me. I'm much happier with ext4 and xfs on lvm.

In the 26 years or so I have used Linux, I have had corrupted filesystems with reiserfs, XFS, btrfs, and ext[23]. In the case of reiserfs and XFS it was practically impossible to recover the filesystem (IIRC reiserfs would reattach anything that resembled a B-tree). For ext[23], it was surprisingly easy to get back most of the data. Never had any corruption with ZFS or ext4. I didn't try to fix the btrfs filesystem,…

My experience with recovering btrfs is that you get back most of your files, but with the content replaced with random gibberish. Which is not too useful.

In a way, I would rather it bomb out and declare a total loss than to keep sinking more time into it as it leads you along.

Re: Linus: Don't Use ZFS

#538

Post by admax88q »

notacoward wrote: post #481
admax88q wrote: post #471

Earlier quoted context omitted.

Java was pretty innovative. The worlds most advanced virtual machine, a JIT that often outperforms C in long running server scenarios, and the foundation of probably 95% of enterprise software.

ANDF had already done (or at least tried to do) the "write once, run anywhere" thing. The JVM followed in the footsteps of similar longstanding efforts at UCSD, IBM and elsewhere. There was some innovation, but "world's most advanced virtual machine" took thousands of people (many of them not at Sun) decades to achieve. Sun's contribution was primarily in popularizing these ideas. Technically, it was just one more st…

Sure plenty of the ideas in Java were invented before, standing on the shoulders of giants and all that. The JIT came from Self, the Object system from Smalltalk, but Java was the first implementation that put all those together into a coherent platform.

Re: Linus: Don't Use ZFS

#539

Post by chungy »

HorstG wrote: post #475
sokoloff wrote: post #408

Earlier quoted context omitted.

I think you mean RAIDZ1, not 5.

Yes. RAIDz (without the "1") was the original RAID5-equivalent, RAIDz2 is equivalent to RAID6. However since nobody really knows what the hell z1 and z2 is and z1 is easy to mix up with RAID1 for nonZFS people, calling it z5 and z6 is far less confusing.

It's the number of parity disks, pretty simple. There has been occasional talk of making the number arbitrary, though presently only raidz1, raidz2, and raidz3 exist.

Re: Linus: Don't Use ZFS

#540

Post by paulmd »

rleigh wrote: post #522
paulmd wrote: post #500

Earlier quoted context omitted.

> Writes in a raidz are always limited to a single disk’s performance what? no. why would that be the case? You lose a single disk's performance due to the checksumming. just from my personal NAS I can tell you that I can do transfers from my scratch drive (NVMe SSD) to the storage array at more than twice the speed of any individual drive in the array... and that's in rsync which is notably slower than a "native" mv…

> what? no. why would that be the case? You lose a single disk's performance due to the checksumming. I think they are probably referring to the write performance of a RAIDZ VDEV being constrained by the performance of the slowest disc within the VDEV.

true, if you have 7 fast disks and one slow disk in a raidz, you get 7 x slow disk performance.
Post reply on HN