Live data from Hacker News

ZFS fans, rejoice – RAIDz expansion will be a thing soon

arstechnica.com

151–160 of 198 posts

Re: ZFS fans, rejoice – RAIDz expansion will be a thing soon

#151
post #2

I'll believe it when I see it, why anyone uses BTRFs (UnRaid or any other form of software raid that isn't ZFS) is still beyond me. At least when we're not talking SSD's ;) ZFS is incredible, curious to mess around with these new features!

BTRFS was useful for me. When those (RAID5) parity patches got rejected many, many years ago for non-technical reasons like not matching a business case/goal or similar, it changed my view of open source. That was the day I realized that some open source participants and supporters are interested in having open source projects that are good enough to act as a barrier to entry, but not good enough to compete with thei…

> (RAID5) parity patches got rejected many, many years ago

Ooooh. (Booo!)

I wouldn't mind a citation/mailinglist reference for this, if you have one. (I honestly have no idea what I'd Google.)

Re: ZFS fans, rejoice – RAIDz expansion will be a thing soon

#152
post #78
post #53

this might sound like a troll comment but its coming from someone with almost zero experience with raid. What is the purpose of ZFS in 2021 if we have hardware RAID and linux software RAID? BTRFS does RAID too. Why would people choose ZFS in 2021 if both Oracle and Open Source users have 2 competing ZFS? are they interoperable?

No matter what happens, people will seemingly forever declare BTRFS is not as stable and not as safe. There's a status page that details what BTRFS thinks of itself[1], and I doubt any of the many people docking BTRFS have read or know or care what that page says. There is one issue still being worked out to completion, a "write hole" problem, involving two separate failures, an unplanned/power-loss shut-down, follow…

I think there were at least 2 - 3 cycle where BTRFS declare itself as good and stable only to have people experiencing yet another Data Loss.

So once they are burnt, they wont come back.

Re: ZFS fans, rejoice – RAIDz expansion will be a thing soon

#153
post #129

Earlier quoted context omitted.

Ah, so Linux is approaching feature parity with FreeBSD jails?

I'm not sure that talking about feature parity even makes sense. What do FreeBSD jails do that Linux can't? I know there's no single jail system call that you can call so you need to assemble the container "manually", but that's an implementation detail as far as I am concerned. On the other hand, true network namespaces (VNET on FreeBSD) have been usable on Linux for longer than on FreeBSD. It's a bit disingenuous t…

Ah, that bait got you.

It's a smug comment that claims something but offers no example at all, not even an anecdotal one.

If FreeBSD jails were so much better than Linux namespaces/containers etc we would be all using FreeBSD by now. The license is even more permissive. Containers have been out for ~ten years now and yet... Here we are.

Re: ZFS fans, rejoice – RAIDz expansion will be a thing soon

#154

I'm starting to get concerned about the ZFS issue list, there are a ton of gotchas hiding in using OpenZFS that will cause data loss: * Swap on ZVOL (data loss) * Hardlocking when removing ZIL (this has caused dataloss for us)

Can you please link me to the issue with swap on zvol causing data loss.

Re: ZFS fans, rejoice – RAIDz expansion will be a thing soon

#155
post #32
post #2

I'll believe it when I see it, why anyone uses BTRFs (UnRaid or any other form of software raid that isn't ZFS) is still beyond me. At least when we're not talking SSD's ;) ZFS is incredible, curious to mess around with these new features!

btrfs does have some advantages over zfs - no data duplicated between page cache and arc - no upgrade problems on rolling distros - balance allows restructuring the array - offline dedup, no need for huge dedup tables - ability to turn off checksumming for specific files - O_DIRECT support - reflink copy - fiemap - easy to resize

Some of these are fair points but zfsonlinux/OpenZFS has had O_DIRECT since 0.8.x.

Re: ZFS fans, rejoice – RAIDz expansion will be a thing soon

#156
post #32

Earlier quoted context omitted.

btrfs does have some advantages over zfs - no data duplicated between page cache and arc - no upgrade problems on rolling distros - balance allows restructuring the array - offline dedup, no need for huge dedup tables - ability to turn off checksumming for specific files - O_DIRECT support - reflink copy - fiemap - easy to resize

Some of these are fair points but zfsonlinux/OpenZFS has had O_DIRECT since 0.8.x.

ZFSOnLinux just ignores the O_DIRECT flag if I remember correctly. Granted, this is what btrfs should do by default as well since there is an ugly issue where software can modify the O_DIRECT buffer after it was submitted causing btrfs checksum errors even though nothing was corrupted (and there is nothing to be done about it except disabling O_DIRECT or creating a buffer copy).

Re: ZFS fans, rejoice – RAIDz expansion will be a thing soon

#157
post #153

Earlier quoted context omitted.

I'm not sure that talking about feature parity even makes sense. What do FreeBSD jails do that Linux can't? I know there's no single jail system call that you can call so you need to assemble the container "manually", but that's an implementation detail as far as I am concerned. On the other hand, true network namespaces (VNET on FreeBSD) have been usable on Linux for longer than on FreeBSD. It's a bit disingenuous t…

Ah, that bait got you. It's a smug comment that claims something but offers no example at all, not even an anecdotal one. If FreeBSD jails were so much better than Linux namespaces/containers etc we would be all using FreeBSD by now. The license is even more permissive. Containers have been out for ~ten years now and yet... Here we are.

And if ZFS was so much better than Linux ext3 we would be all using Solaris, right? ;-)

The market doesn’t work like that.

Re: ZFS fans, rejoice – RAIDz expansion will be a thing soon

#158
post #89
post #45

Earlier quoted context omitted.

I've had 3 catastrophic BTRFS failures. In two cases, the root filesystem just ran out of space and there was no way to repair the partition. Last time, the partition was just rendered unmountable after a reboot. All data was lost.No such thing has ever happened with ZFS for me.

A recent Fedora install here came with a new default of BTRFS use rather than ext4. So i'm curious about your experience, were any of those catastrophic failures recent? Do you know of any patches entering the kernel that purport to fix the issues you experienced?

Last one was two years ago. I was told that it was a hardware issue. Same SSD is still going strong with ext4 now.

Re: ZFS fans, rejoice – RAIDz expansion will be a thing soon

#159
post #77
post #71

Earlier quoted context omitted.

Since all those tools are from different dev's the system gets more complex. But hey if you really think that ZFS is to complex to hold 55 petabytes because it has to many potential bugs you should tell them: https://computing.llnl.gov/projects/zfs-lustre

Thankfully I don't have to manage 55 petabytes of data, but good luck to them. Did you miss the part where I mentioned "for personal use"? > Since all those tools are from different dev's the system gets more complex. I fail to see the connection there. Whether software is developed by a single entity or multiple developers has no relation to how complex the end user system will be. But many small tools focused on ju…

>Did you miss the part where I mentioned "for personal use"?

Since ZFS is simpler to use then your setup, is used to store 55PB of data without a single bit error since 2012, i don't see why someone should use inferior stuff, even when it's "personal use".

>But many small tools focused on just the functionality I need allows me to build a simpler system overall.

Sometimes monoliths are better for example the network-stack and storage....maybe kernels (big Maybe here)

Re: ZFS fans, rejoice – RAIDz expansion will be a thing soon

#160
post #133

The article is a great example of all the somewhat surprising peculiarities in ZFS. For example, the conversion will keep the stripe width and block size, meaning your throughput of existing data won't improve. So it's not quite a full re-balance. Other fun things are the flexible block sizes and their relation to the size you're writing and compression ... Chris Siebenmann has written quite a bit about it ( https://…

There is also a linear degradation of metadata/blockinfo performance (in the order of the number of rewrites) due to the need to check multiple possible locations for the block pointer. In practice this probably just means more RAM utilization but... eh. Even as a home user, I've become convinced the juice is not worth the squeeze. For serious use, just buy four drives at a time and upgrade four drives at a time. Tha…

> Meanwhile ZFS is far far better than the alternatives (btrfs) in terms of data integrity and reliability.

No, it's not. Btrfs is nowadays perfectly reliable as long as you avoid the in development features which are all explicitly marked as in development and will warn you. That's why Facebook uses it in production. It also has some nice advantage for home use. Btrfs pools are a lot simpler to manage and have less quirks than ZFS.

> Maybe it is just stockholm syndrome but do you really, really need to dynamically expand your array by an arbitrary number of disks that badly? There is ultimately no way around the reliability question so you can't expand forever and if you're serious about setting up a nice fileserver that'll be reliable for the long run, putting 4 drives in it isn't that bad.

Btrfs will do that just fine for example. That's really a limitation of ZFS.

I wish ZFS users would just stop FUDing about btrfs. Most of them haven't touched it for a decade and keep paroting the same old things.

Post reply on HN