Live data from Hacker News

Linus: Don't Use ZFS

realworldtech.com

231–240 of 571 posts

Re: Linus: Don't Use ZFS

#231
post #118

Earlier quoted context omitted.

The problem with most of these is you have to bring the system down to do maintenance. You can do a scrub on zfs while it's up.

Most non-hobbyist RAID hardware does online-scrub just fine (not that I would recommend wasting money on such hw). Btw, ZFS scrub is not only a RAID-block-check but also a partial fsck, so its not really comparable.

We used the LSI 9286CV-8e (or dell equivalent) which was somewhere between $1000-$1500 back in the day. Worth it compared to babysitting any software RAID IMO.

Re: Linus: Don't Use ZFS

#232

Alright, Linus, I'll make you a deal: I'll consider dropping ZFS when you ship a production-grade BTRFS (or reiserfs or anything else with the same features).

Is reiserfs still maintained. After Hans went to prison I didn't think there was much left beyond stagnation.

I think his parole hearing is coming up this year...

Re: Linus: Don't Use ZFS

#233
post #139
post #112

Earlier quoted context omitted.

Group your disks in bunches of 4 or 5 per Raidz, no more. And have them on the same controller or SAS-expander per bunch. Use striping over the bunches. Don't use hotspares, for performance maybe avoid RAIDz6. Try out and benchmark a lot. Get more RAM, lots more RAM.

Back when I setup my last ZFS running on OmniOS 5 disks was not optimal, though i am running RAIDZ2 But yes, lots of RAM

I think the optimal number of RAIDz5 disks is 3, if you just want performance. But this wastes lots of space of course. Also, the number of SAS/SATA-channels per controller and the topology of expanders is important. Thats why I don't think there is a recipy, you have to try it out for each new kind of hardware.

And as another thread pointed out, stripe size is also an important parameter.

Re: Linus: Don't Use ZFS

#234
post #38

Earlier quoted context omitted.

btrfs is not at all reliable, so if you care about your files staying working files, it probably doesn't meet your requirements. It is like the MongoDB 0.1 of filesystems.

Seems pretty reliable these days. Are you commenting based upon personal experience? If so, when was it that you used btrfs?

I have a laptop running opensuse, with root on btrfs. Twice I have had to reinstall because it managed to corrupt the file system.

Re: Linus: Don't Use ZFS

#236
> and given Oracle's interface copyright suits (see Java)

This seems pretty ironic, given that the whole problem is Linux developers trying to claim and enforce that only other GPL code is allowed to use its APIs (which, IMHO, goes beyond both the intent and letter of the license). The issues aren't exactly the same, but Linux sure seems to be a lot closer to Oracle than to Google here.

Re: Linus: Don't Use ZFS

#237
post #22

Earlier quoted context omitted.

Well he had this: > as far as I can tell, it has no real maintenance behind it either any more Which simply isn't true. They just released a new ZFS version with encryption built in (no more ZFS + LUKS) and they removed the SPL dependency (which didn't support Linux 5.0+ anyway). I use ZFS on my Linux machines for my storage and I've been rather happy with it.

Same, for at least 6 years in a 4 drive zraid array. It always reads and writes at full gigabit ethernet speeds and I haven't had any downtime other than maintaining FreeBSD updates which are trivial even when going from 10.x to 11 to 12.

"Same" for the last ~4 years, starting with 8 disks and as of 2018, the 24-bay enclosure is full. Each vdev is a mirrored pair split across HBAs to sedate my paranoia. I've replaced a few drives after watching unreadable sector count slowly increase over a few months. I've also switched out most of the original 3TB pairs to 8TB and 10TB pairs. ~42TB usable and the box only has 16GB of RAM (because I can't get the used 32GB sticks to work, it's a picky mainboard and difficult to find matching ECC memory here in Europe). I haven't powered down much except to attempt to replace the RAM or during extremely hot days. Read/write speed is more or less max gigabit, even during rebuild after hot-swapping drives.

Re: Linus: Don't Use ZFS

#238
"Oracle's litigious nature". What a beautifully short and concise phrase. I immediately had to write this down and stash it as an argument for the next time someone at work pushes to go for "Oracle $product" after having received a bottle of wine from their sales team.

Re: Linus: Don't Use ZFS

#239
post #138

He's not wrong. ext4 is actually maintained. This matters. ZFS hasn't kept up with SSDs. ZFS partitions are also almost impossible to resize, which is a huge deal in today's world of virtualized hardware. Honestly Linus's attitude is refreshing. It's a sign that Linux hasn't yet become some stiff design-by-committee thing. One guy ranting still calls the shots. I love it. Protect this man at all costs.

> ZFS hasn't kept up with SSDs. Pretty sure this is false. ZFS does support trim (FreeBSD had trim support for quite a while, but ZoL has it now as well), as well as supporting l2arc and zil/slog on ssd. > ZFS partitions are also almost impossible to resize You can grow zfs partitions just fine (and even online expand). You just can't shrink them.

> You just can't shrink them.

That's not even entirely true, though it requires shuffling around with multiple vdevs temporarily and doesn't presently support raidz. Also vdev removal is primarily made to support an accidental "oops, I added a disk I shouldn't have" rather than removing a long-lived device -- there's no technical restriction against the later case, though the redirect references could hamper performance.

The official stance has always been to send/receive to significantly change a pool's geometry where it isn't possible online.

Re: Linus: Don't Use ZFS

#240

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.

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.
Post reply on HN