Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ZFS 2.3 released with ZFS raidz expansion

github.com

Post reply on HN
Print view View original

191–200 of 331 posts

Re: ZFS 2.3 released with ZFS raidz expansion

#191

Post by zamadatix »

poisonborz wrote: post #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 f…

NTFS was able to be extended in various way over the years to the point what you could do with an NTFS drive 32 years ago will feel like talking about a completely different filesystem than what you can do with it on current Windows.

Honestly I really like ReFS, particularly in context of storage spaces, but I don't think it's relevant to Microsoft's consumer desktop OS where users don't have 6 drives they need to pool together. Don't get me wrong, I use ZFS because that's what I can get running on a Linux server and I'm not going to go run Windows Server just for the storage pooling... but ReFS + Storage Spaces wins my heart with the 256 MB slab approach. This means you can add+remove mixed sized drives and get the maximum space utilization for the parity settings of the pool. Here ZFS is still getting to online adds of same or larger drives 10 years later.

Re: ZFS 2.3 released with ZFS raidz expansion

#192

Post by magicalhippo »

rekoil wrote: post #152
uniqueuid wrote: post #4

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…

Yaeh it's a pretty huge caveat to be honest. Da1 Db1 Dc1 Pa1 Pb1 Da2 Db2 Dc2 Pa2 Pb2 Da3 Db3 Dc3 Pa3 Pb3 ___ ___ ___ Pa4 Pb4 ___ represents free space. After expansion by one disk you would logically expect something like: Da1 Db1 Dc1 Da2 Pa1 Pb1 Db2 Dc2 Da3 Db3 Pa2 Pb2 Dc3 ___ ___ ___ Pa3 Pb3 ___ ___ ___ ___ Pa4 Pb4 But as I understand it it would actually expand to: Da1 Db1 Dc1 Dd1 Pa1 Pb1 Da2 Db2 Dc2 Dd2 Pa2 Pb2 D…

Unless I misunderstood you, you're describing more how classical RAID would work. The RAID-Z expansion works like you note you would logically expect. You added a drive with four blocks of free space, and you end up with four blocks more of free space afterwards.

You can see this in the presentation[1] slides[2].

The reason this is sub-optimal post-expansion is because, in your example, the old maximal stripe width is lower than the post-expansion maximal stripe width.

Your example is a bit unfortunate in terms of allocated blocks vs layout, but if we tweak it slightly, then

    Da1 Db1 Dc1 Pa1 Pb1
    Da2 Db2 Dc2 Pa2 Pb2
    Da3 Db3 Pa3 Pb3 ___
would after RAID-Z expansion would become

    Da1 Db1 Dc1 Pa1 Pb1 Da2
    Db2 Dc2 Pa2 Pb2 Da3 Db3 
    Pa3 Pb3 ___ ___ ___ ___
Ie you added a disk with 3 new blocks, and so total free space after is 1+3 = 4 blocks.

However if the same data was written in the post-expanded vdev configuration, it would have become

    Da1 Db1 Dc1 Dd1 Pa1 Pb1
    Da2 Db2 Dc2 Dd2 Pa2 Pb2
    ___ ___ ___ ___ ___ ___
Ie, you'd have 6 free blocks not just 4 blocks.

Of course this doesn't count for writes which end up taking less than the maximal stripe width.

[1]: https://www.youtube.com/watch?v=tqyNHyq0LYM

[2]: https://openzfs.org/w/images/5/5e/RAIDZ_Expansion_2023.pdf

Re: ZFS 2.3 released with ZFS raidz expansion

#193

Post by zamadatix »

wkat4242 wrote: post #189
badgersnake wrote: post #66

Earlier quoted context omitted.

NTFS is good enough for most people, who have a laptop with one SSD in it.

The benefits of ZFS don't need multiple drives to be useful. I'm running ZFS on root for years now and snapshots have saved my bacon several times. Also with block checksums you can at least detect bitrot. And COW is always useful.

Windows manages volume snapshots on NTFS through VSS. I think ZFS snapshots are a bit "cleaner" of a design, and the tooling is a bit friendlier IMO, but the functionality to snapshot, rollback, and save your bacon is there regardless. Outside of the automatically enabled "System Restore" (which only uses VSS to snapshot specific system files during updates) I don't think anyone bothers to use it though.

CoW, advanced parity, and checksumming are the big ones NTFS lacks. CoW is just inherently not how NTFS is designed and checksumming isn't there. Anything else (encryption, compression, snapshots, ACLs, large scale, virtual devices, basic parity) is done through NTFS on Windows.

Re: ZFS 2.3 released with ZFS raidz expansion

#194

Post by tpetry »

dizhn wrote: post #78
nesarkvechnep wrote: post #35

Earlier quoted context omitted.

I'm trying to find a reason not to use ZFS at home.

Requirement for enterprise quality disks, huge RAM (1 gig per TB), ECC, at least x5 disks of redundancy. None of these are things, but people will try to educate you anyway. So use it but keep it to yourself. :)

The interesting part about the enterprise quality disk misinformation is how so wrong it is. The core idea of ZFS was to detect issues when those drives or their drivers are faulty. And this was more happening with cheap non-enterprise disks at that time.

Re: ZFS 2.3 released with ZFS raidz expansion

#195

Post by pdimitar »

bluGill wrote: post #183
poisonborz wrote: post #161

Earlier quoted context omitted.

So private consumers should just pay cloud subscription if they want safer/modern data storage for their PC? (without NAS)

Probably. There are levels of backups, and a cloud subscription SHOULD give you copies in geographical separate locations with someone to help you (who probably isn't into computers and doesn't want to learn the complex details) restore when (NOT IF!) needed. I have all my backups on a NAS in the next room. This covers the vast majority of use cases for backups, but if my house burns down everything is lost. I know I…

My setup is similar to yours, but I also distribute my most important data in compressed (I lost faith in most paid operators. Whoops, this thing that absolutely can happen to home users and we're supposed to protect them from now actually happened to us and we were not prepared. We're so sorry!

Nah. Give me access to 5-15 cloud storage accounts, I'll handle it myself. Have done so for years.

Re: ZFS 2.3 released with ZFS raidz expansion

#196

Post by adgjlsfhk1 »

CoolCold wrote: post #105
ryao wrote: post #83

Earlier quoted context omitted.

My thinkpad from college uses ZFS as its rootfs. The benefits are: * If the hard drive / SSD corrupted blocks, the corruption would be identified. * Ditto blocks allow for self healing. Usually, this only applies to metadata, but if you set copies=2, you can get this on data too. It is a poor man’s RAID. * ARC made the desktop environment very responsive since unlike the LRU cache, ARC resists cold cache effects from…

NTFS had compression since mot even sure when. For other stuff, let that nerdy CorpIT handle your system.

yes but NTFS is bad enough that no one needs to be told how bad it is.

Re: ZFS 2.3 released with ZFS raidz expansion

#197

Post by ryao »

magicalhippo wrote: post #192
rekoil wrote: post #152

Earlier quoted context omitted.

Yaeh it's a pretty huge caveat to be honest. Da1 Db1 Dc1 Pa1 Pb1 Da2 Db2 Dc2 Pa2 Pb2 Da3 Db3 Dc3 Pa3 Pb3 ___ ___ ___ Pa4 Pb4 ___ represents free space. After expansion by one disk you would logically expect something like: Da1 Db1 Dc1 Da2 Pa1 Pb1 Db2 Dc2 Da3 Db3 Pa2 Pb2 Dc3 ___ ___ ___ Pa3 Pb3 ___ ___ ___ ___ Pa4 Pb4 But as I understand it it would actually expand to: Da1 Db1 Dc1 Dd1 Pa1 Pb1 Da2 Db2 Dc2 Dd2 Pa2 Pb2 D…

Unless I misunderstood you, you're describing more how classical RAID would work. The RAID-Z expansion works like you note you would logically expect. You added a drive with four blocks of free space, and you end up with four blocks more of free space afterwards. You can see this in the presentation[1] slides[2]. The reason this is sub-optimal post-expansion is because, in your example, the old maximal stripe width i…

Your diagrams have some flaws too. ZFS has a variable stripe size. Let’s say you have a 10 disk raid-z2 vdev that is ashift=12 for 4K columns. If you have a 4K file, 1 data block and 2 parity blocks will be written. Even if you expand the raid-z vdev, there is no savings to be had from the new data:parity ratio. Now, let’s assume that you have a 72K file. Here, you have 18 data blocks and 6 parity blocks. You would benefit from rewriting this to use the new data:parity ratio. In this case, you would only need 4 parity blocks. ZFS does not rewrite it as part of the expansion, however.

There are already good diagrams in your links, so I will refrain from drawing my own with ASCII. Also, ZFS will vary which columns get parity, which is why the slides you linked have the parity at pseudo-random locations. It was not a quirk of the slide’s author. The data is really laid out that way.

Re: ZFS 2.3 released with ZFS raidz expansion

#198

Post by johannes1234321 »

kwanbix wrote: post #64
poisonborz wrote: post #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 f…

Honest question. As an end user that uses Windows and Linux and does not uses ZFS, what I am missing?

For a while I ran Open Solaris with ZFS as root filesystem.

The key feature for me, which I miss, is the snapshotting integrated into the package manager.

ZFS allows snapshots more or less for free (due to copy on weite) including cron based snapshotting every 15 minutes. So if I did a mistake anywhere there was a way to recover.

And that integrated with the update manager and boot manager means that on an update a snapshot is created and during boot one can switch between states. Never had a broken update, but gave a good feeling.

On my home server I like the raid features and on Solaris it was nicely integrated with NFS etc so that one can easily create volumes and export them and set restrictions (max size etc.) on it.

Re: ZFS 2.3 released with ZFS raidz expansion

#199

Post by [deleted] »

ryao wrote: post #197
magicalhippo wrote: post #192

Earlier quoted context omitted.

Unless I misunderstood you, you're describing more how classical RAID would work. The RAID-Z expansion works like you note you would logically expect. You added a drive with four blocks of free space, and you end up with four blocks more of free space afterwards. You can see this in the presentation[1] slides[2]. The reason this is sub-optimal post-expansion is because, in your example, the old maximal stripe width i…

Your diagrams have some flaws too. ZFS has a variable stripe size. Let’s say you have a 10 disk raid-z2 vdev that is ashift=12 for 4K columns. If you have a 4K file, 1 data block and 2 parity blocks will be written. Even if you expand the raid-z vdev, there is no savings to be had from the new data:parity ratio. Now, let’s assume that you have a 72K file. Here, you have 18 data blocks and 6 parity blocks. You would b…

[deleted]

Re: ZFS 2.3 released with ZFS raidz expansion

#200

Post by magicalhippo »

ryao wrote: post #197
magicalhippo wrote: post #192

Earlier quoted context omitted.

Unless I misunderstood you, you're describing more how classical RAID would work. The RAID-Z expansion works like you note you would logically expect. You added a drive with four blocks of free space, and you end up with four blocks more of free space afterwards. You can see this in the presentation[1] slides[2]. The reason this is sub-optimal post-expansion is because, in your example, the old maximal stripe width i…

Your diagrams have some flaws too. ZFS has a variable stripe size. Let’s say you have a 10 disk raid-z2 vdev that is ashift=12 for 4K columns. If you have a 4K file, 1 data block and 2 parity blocks will be written. Even if you expand the raid-z vdev, there is no savings to be had from the new data:parity ratio. Now, let’s assume that you have a 72K file. Here, you have 18 data blocks and 6 parity blocks. You would b…

What are the errors? I tried to show exactly what you talk about.

edit: ok, I didn't consider the exact locations of the parity, I was only concerned with space usage.

The 8 data blocks need three stripes on a 3+2 RAID-Z2 setup both pre and post expansion, the last being a partial stripe, but when written in the 4+2 setup only needs 2 full stripes, leading to more total free space.

Post reply on HN