Live data from Hacker News

ZFS 2.3 released with ZFS raidz expansion

github.com

51–60 of 331 posts

Re: ZFS 2.3 released with ZFS raidz expansion

#51

It's good to see that they were pretty conservative about the expansion. Not only is expansion completely transparent and resumable, it also maintains redundancy throughout the process. That said, there is one tiny caveat people should be aware of: > After the expansion completes, old blocks remain with their old data-to-parity ratio (e.g. 5-wide RAIDZ2, has 3 data to 2 parity), but distributed among the larger set o…

I'm not sure that's really a caveat, it just means old data might be in an inoptimal layout. Even with that, you still get the full benefits of raidzN, where up to N disks can completely fail and the pool will remain functional.

Re: ZFS 2.3 released with ZFS raidz expansion

#52
post #39

Can someone describe why they would use ZFS (or similar) for home usage?

It's relatively easy, and yet powerful. Before that I had MDADM + LVM + dm-crypt + ext4, which also worked but all the layers got me into a headache. Automated snapshots are super easy and fast. Also easy to access if you deleted a file, you don't have to restore the whole snapshot, you can just cp from the hidden .zfs/ folder. I run it on 6x 8TB disk for a couple of years now. I run it in a raidz2, which means up to…

> Would I use it on a single disk on a Desktop? Probably not.

I do. Snapshots and replication and checksumming are awesome.

Re: ZFS 2.3 released with ZFS raidz expansion

#53
post #18

Earlier quoted context omitted.

You need to buy the same exact drive with the same capacity and speed. Your raidz vdev be as small and as slow as your smallest and slowest drive. btrfs and the new bcachefs can do RAID with mixed drives, but I can’t trust either of them with my data yet.

Just have backups. I used btrfs and zfs for different purposes. Never had any lost data or downtime with btrfs since 2016. I only use raid 0 and raid 1 and compression. Btrfs does not havr a hungry ram requirement.

Neither does zfs, that’s a widely repeated red herring from people trying to do dedup in the very early days, and people who misunderstood how it used ram to do caching.

Re: ZFS 2.3 released with ZFS raidz expansion

#54
post #44
post #36

Earlier quoted context omitted.

Well, then they made a design choice in their RAID implementation that made fairly reasonable things hard. I don't know what md does if the parity doesn't match up, no. (I've never ever had that happen, in more than 25 years of pretty heavy md use on various disks.)

I am not sure if reshaping is a reasonable thing. It is not so reasonable in other fields. In architecture, if you build a bridge and then want more lanes, you usually build a new bridge, rather than reshape the bridge. The idea of reshaping a bridge while cars are using it would sound insane there, yet that is what people want from storage stacks. Reshaping traditional storage stacks does not consider all of the way…

> I am not sure if reshaping is a reasonable thing.

Yet people are celebrating when ZFS adds it. Was it all for nothing?

Re: ZFS 2.3 released with ZFS raidz expansion

#55
post #54
post #44

Earlier quoted context omitted.

I am not sure if reshaping is a reasonable thing. It is not so reasonable in other fields. In architecture, if you build a bridge and then want more lanes, you usually build a new bridge, rather than reshape the bridge. The idea of reshaping a bridge while cars are using it would sound insane there, yet that is what people want from storage stacks. Reshaping traditional storage stacks does not consider all of the way…

> I am not sure if reshaping is a reasonable thing. Yet people are celebrating when ZFS adds it. Was it all for nothing?

People wanted it, but it was very hard to do safely. While ZFS now can do it safely, many other storage solutions cannot.

Those corruption issues I mentioned, where the RAID controller has no idea what to do, affect far more than just reshaping. They affect traditional RAID arrays when disks die and when patrol scrubs are done. I have not tested MD RAID on edge cases lately, but the last time I did, I found MD RAID ignored corruption whenever possible. It would not detect corruption in normal operation because it assumed all data blocks are good unless SMART said otherwise. Thus, it would randomly serve bad data from corrupted mirror members and always serve bad data from RAID 5/6 members whenever the data blocks were corrupted. This was particularly tragic on RAID 6, where MD RAID is hypothetically able to detect and correct the corruption if it tried. Doing that would come with such a huge performance overhead that it is clear why it was not done.

Getting back to reshaping, while I did not explicitly test it, I would expect that unless a disk is missing or disappears during a reshape, MD RAID would ignore any corruption that can be detected using parity and assume all data blocks are good just like it does in normal operation. It does not make sense for MD RAID to look for corruption during a reshape operation, since not only would it be slower, but even if it finds corruption, it has no clue how to correct the corruption unless RAID 6 is used, there are no missing/failed members and the affected stripe does not have any read errors from SMART detecting a bad sector that would effectively make it as if there was a missing disk.

You could do your own tests. You should find that ZFS handles edge cases where the wrong thing is in a spot where something important should be gracefully while MD RAID does not. MD RAID is a reimplementation of a technology from the 1960s. If 1960s storage technology handled these edge cases well, Sun Microsystems would not have made ZFS to get away from older technologies.

Re: ZFS 2.3 released with ZFS raidz expansion

#56

Can someone describe why they would use ZFS (or similar) for home usage?

Good reasons for me:

Checksums: this is even more important in home usage as the hardware is usually of lower quality. Faulty controllers, crappy cables, hard disks stored in a higher than advised temperature... many reasons for bogus data to be saved, and zfs handles that well and automatically (if you have redundancy)

Snapshots: very useful to make backups and quickly go back to an older version of a file when mistakes are made

Ease of mind: compared to the alternatives, I find that zfs is easier to use and makes it harder to make a mistake that could bring data loss (e.g. remove by mistake the wrong drive when replacing a faulty one, pool becomes unusable, "ops!", put the disk back, pool goes back to work as nothing happened). Maybe it is different now with mdadm, ma when I used it years ago I was always worried to make a destructive mistake.

Re: ZFS 2.3 released with ZFS raidz expansion

#57
post #44
post #36

Earlier quoted context omitted.

Well, then they made a design choice in their RAID implementation that made fairly reasonable things hard. I don't know what md does if the parity doesn't match up, no. (I've never ever had that happen, in more than 25 years of pretty heavy md use on various disks.)

I am not sure if reshaping is a reasonable thing. It is not so reasonable in other fields. In architecture, if you build a bridge and then want more lanes, you usually build a new bridge, rather than reshape the bridge. The idea of reshaping a bridge while cars are using it would sound insane there, yet that is what people want from storage stacks. Reshaping traditional storage stacks does not consider all of the way…

[deleted]

Re: ZFS 2.3 released with ZFS raidz expansion

#58
post #11
post #10

Earlier quoted context omitted.

Bcachefs allows it

Cool, just have to wait before it is stable enough for daily use of mission critical data. I am personally optimistic about bcachefs, but incredibly pessimistic about changing filesystems.

It seems easier to copy data to a new ZFS pool if you need to remove RAID-Z top level vdevs. Another possibility is to just wait for someone to implement it in ZFS. ZFS already has top level vdev removal for other types of vdevs. Support for top level raid-z vdev removal just needs to be implemented on top of that.

Re: ZFS 2.3 released with ZFS raidz expansion

#59
I just don't get it how the Windows world - by far the largest PC platform per userbase - still doesn't have any answer to ZFS. Microsoft had WinFS and then ReFS but it's on the backburner and while there is active development (Win11 ships some bits time to time) release is nowhere in sight. There are some lone warriors trying the giant task of creating a ZFS compatibility layer with some projects, but they are far from being mature/usable.

How come that Windows still uses a 32 year old file system?

Re: ZFS 2.3 released with ZFS raidz expansion

#60
post #13

Earlier quoted context omitted.

> It is possible with windows storage space (remove drive from a pool) and mdadm/lvm (remove disk from a RAID array, remove volume from lvm), which to me are the two major alternatives. Don't know about unraid. Perhaps I am misunderstanding you, but you can offline and remove drives from a ZFS pool. Do you mean WSS and mdadm/lvm will allow an automatic live rebalance and then reconfigure the drive topology?

So for instance I have a ZFS pool with 3 HDD data vdevs, and 2 SSD special vdevs. I want to convert the two SSD vdevs into a single one (or possibly remove one of them). From what I read the only way to do that is to destroy the entire pool and recreate it (it's in a server in a datacentre, don't want to reupload that much data). In windows, you can set a disk for removal, and as long as the other disks have enough s…

The man page says that your example is doable with zpool remove:

https://openzfs.github.io/openzfs-docs/man/master/8/zpool-re...

Post reply on HN