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

521–530 of 571 posts

Re: Linus: Don't Use ZFS

#521

Post by bitL »

rhinoceraptor wrote: post #517
bitL wrote: post #499

Earlier quoted context omitted.

I worked at SUN when ZFS was "invented" and the emphasis on a large amount of proper ECC memory was strong, especially in conjunction with Solaris Zones. I can't recall if it was 1GB of RAM per 1TB of storage or something similar due to how it performed deduplication and stored indices in hot memory. And that was also the reason for insisting on ECC, in order to make sure you won't get your stored indices and shared…

I can see how a (perhaps, less than competitive) hardware company would want you to think that :)

Sure, all about internal marketing, right? :D

But there was nothing like that on the market at that time anyway.

Re: Linus: Don't Use ZFS

#522

Post by rleigh »

paulmd wrote: post #500
montjoy wrote: post #81

Earlier quoted context omitted.

Last time I used ZFS write performance was terrible compared to an ordinary RAID5. IIRC Writes in a raidz are always limited to a single disk’s performance. The only way to get better write speed is to combine multiple raidzs - which means you need a boatload if disks.

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

Re: Linus: Don't Use ZFS

#523

Post by mekster »

starfallg wrote: post #123
forgotpwd16 wrote: post #111

Earlier quoted context omitted.

>stop wasting money on BTRFS You're saying they should stop supporting a project that was considered stable by the time the other started being developed. Why do that? What makes Bcachefs a better choice?

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.

Funny the other day on another HN thread, someone was saying btrfs is good even though I said RedHat has abandoned the btrfs ship but then he said Facebook had been using it heavily.

But seeing how so many people had lost data using it, I will never use btrfs...

Re: Linus: Don't Use ZFS

#524

Post by mekster »

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

When was it that XFS got corrupted on you? I think as RedHat embraces XFS, I assume it's quite good now.

Re: Linus: Don't Use ZFS

#525

Post by mekster »

ggm wrote: post #240
zippergz wrote: post #199

Earlier quoted context omitted.

I know this isn't an option for everyone, but this is part of why I run FreeBSD instead of Linux for servers where I need ZFS.

This isn't why I started running FreeBSD, but it is also one of the reasons I continue to run FreeBSD.

Yes, I run Linux for business but keep a FreeBSD personally so I'm used to it in case I need zfs for business.

Re: Linus: Don't Use ZFS

#526

Post by lmilcin »

rleigh wrote: post #520
the_why_of_y wrote: post #514

Earlier quoted context omitted.

FreeBSD does not really have a stable ABI; every major release breaks the ABI, so it's only stable for 2 years. https://wiki.freebsd.org/VendorInformation

Stable for each major and minor release is still a vast step up on Linux. Having a stable ABI for two years is vastly easier to support than an ABI which changes every two weeks. This is reflected by the number of binary modules which are packaged for FreeBSD in the ports tree, and provided by third-party vendors. This stability makes it possible to properly support for a reasonable timeframe, and vendors are doing s…

Honestly, I don't like binary modules and I am happy with policy that let's me have functional operating system with modern hardware with source code that I have access to (well... except the firmware that even Linux can't do anything about until open-source hardware projects get more traction).

It is enough that almost all devices around me have a bunch of running code that I have absolutely no control over. I need at least one computer I can trust to do MY bidding.

Re: Linus: Don't Use ZFS

#527

Post by freedomben »

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.

Stratis and VDO have a lot of promise, although it's still a little early. The approach that Stratis has taken is refreshing. It's very simple and reuses lots of already existing stuff so by the time it's released it will already be mature (since the underlying code has been running for many years).

Once a little more guidance comes out about how to properly use VDO and Stratis together, I'll move my personal stuff to it.

Re: Linus: Don't Use ZFS

#528

Post by XelNika »

bleuarff wrote: post #396
XelNika wrote: post #361

Earlier quoted context omitted.

> 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). What makes you say that? I've seen plenty of people make this claim based on URE rates, but I've also not seen any evidence that it is a real problem for a 3-4 drive setup. Modern drives are specced at 1 URE per 10^15 bits read (or better), so less than 1 URE in 125 TB read. Even…

Last time I checked (a few years ago I must say), a 10^15 URE was only for enteprise-grade drives and not for consumer-level, where most drives have a 10^14 URE. Which means your build is almost guaranteed to fail on a large-ish raid setup. So yeah, RAID is still feasible with multi-TB disks if you have the money to buy disks with the appropriate reliability. For the common folk, raid is effectively dead with today's…

I have a couple of Seagate IronWolf drives that are rated at 1 URE per 10^15 bits read and, sure, depending on the capacity you want (basically 8 TB and smaller desktop drives are super cheap), they do cost up to 40% more than their Barracuda cousins, but we're still well within the realm of cheap SATA storage.

Re: Linus: Don't Use ZFS

#529

Post by dekhn »

rleigh wrote: post #519
dekhn wrote: post #144

Earlier quoted context omitted.

do you have lots of snapshots? every snapshotting FS I've worked with has really slow deletes, especially when the volume is near capacity.

Snapshots are one thing ZFS is fast at. All the blocks for a given snapshot are placed on a "deadlist". Snapshot deletion is essentially just returning this list of blocks back to the free pool. A terabyte snapshot will take a short while (in the background) to recycle those blocks. But the deletion itself is near instantaneous.

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

Re: Linus: Don't Use ZFS

#530

Post by mekster »

kova12 wrote: post #338
maccam94 wrote: post #214

Earlier quoted context omitted.

zfsonlinux added support for TRIM last year. Are you referring to something else?

"last year" means it's in very few distributions at this time. Encryption is another feature that is technically supported, but just been added. When I built my NAS last year, I had to use dm-crypt because zfs didn't have it. Some features indeed lag pretty badly in zfs

Is the first party that is Oracle making any efforts to develop zfs further at this point? Is ZoL the primary development team at this time?
Post reply on HN