ZFS AnyRaid in ZFS

They really need to add chapters to their videos for each talk. It’s a pain in the a** to scroll a long video and wait for buffering just to skip forward or backwards to the talk I want to watch. Don’t just dump the entire stream and forget it.

Organizers. Fix this.
 
If the 2 and the 8 are the only drives you have, and you asked for a 2-way mirror, your 2-way mirror will only have 2TB capacity. I guess the remainder of the 8TB could be used for non-redundant storage if you like to use that.

The interesting case is if you have for example a 2, 5 and 8 TB drive, and ask for a mirror: You will get 7 TB capacity. And if you replace the 2 with a new 12 TB, your usable mirrored capacity will go up to 12.5 TB, using every single byte of the disks.

With wider layouts (in particular the ones that are commonly used with RAID-Z and -Z2/-Z3), the combinatorics gets tricky, and figuring out the capacity on the back of an envelope may be too difficult.
 
victort said:
So if I have a 2TB and an 8TB drive, and the 8 goes shot with 80 percent storage, what happens?
Click to expand...

For anyraid to work you need one disk more than your redundancy count.

So if your redundancy is 2-way mirror you need at least 3 disks.
 
Maturin said:
Music is too annoying. Unwatchable.
Click to expand...
  1. 00:08:29 - @cracauer 's link start time *
  2. 00:08:30 - Allan Jude start talking *
  3. 00:10:22 - no more music during the remainder of the talk
  4. 01:00:40 - Allan Jude ends his presentation
I'd say a bit of perseverance goes a long way.

___
* My "guess" is that at the beginning of the presentation, someone didn't cut out the music in time at the mixer.
 
I think this is rather intriguing. In general, it's probably always going to be a bit better to have drives that are basically the same size, however, this does help a bit when that's not the same case, such as when there's a slight mismatch in capacity between drives of the "same" size that aren't exactly due to rounding errors or if you want to replace a couple drives with larger disks while saving up/allowing for replication before placing the remainders in there.
 
cracauer@ said:
Apologies for the music.

There is a webinar on this tomorrow if you want a fresh feed:
klarasystems.com

Understanding AnyRAID: Architecture, Use-Cases, and Tradeoffs - Klara Systems

Join Allan Jude and Jon Panozzo to learn how AnyRAID mixed-drive storage unlocks more usable ZFS capacity, flexible pool expansion, and efficient mixed-disk layouts.
klarasystems.com
Click to expand...
In addition, after registering, I got an invite for FreeBSD After Hours AMA:
Join our post-conference
BSD discussion on June 30, 2026.

Following BSDCan 2026, Allan Jude and Kyle Evans are hosting a live Ask Me Anything session to break down the biggest FreeBSD, OpenZFS, and infrastructure announcements from the conference.

Bring your questions — this is an open discussion built for engineers in production environments.
Click to expand...
I think, these AMA's, will also appear later and be generally available, anyhow this should allow one to be there live as well.
 
Beastie7 said:
They really need to add chapters to their videos for each talk. It’s a pain in the a** to scroll a long video and wait for buffering just to skip forward or backwards to the talk I want to watch. Don’t just dump the entire stream and forget it.

Organizers. Fix this.
Click to expand...
You are watching a recording of the live stream. The individual talks will be posted as separate videos once the team of volunteers has time to cut the recordings and stitch the feeds together etc.
 
hedwards said:
I think this is rather intriguing. In general, it's probably always going to be a bit better to have drives that are basically the same size, however, this does help a bit when that's not the same case, such as when there's a slight mismatch in capacity between drives of the "same" size that aren't exactly due to rounding errors or if you want to replace a couple drives with larger disks while saving up/allowing for replication before placing the remainders in there.
Click to expand...
In the case of a rounding error of difference, ZFS already does the right thing, as its metaslabs are all the same size, usually 16 GB, so any fractional remainder won't get used and won't cause a problem if the new drive is a few sectors shorter.
 
allanjude@ said:
In the case of a rounding error of difference, ZFS already does the right thing, as its metaslabs are all the same size, usually 16 GB, so any fractional remainder won't get used and won't cause a problem if the new drive is a few sectors shorter.
Click to expand...
It's been a while since I tried, but I thought that only applied when creating a new mirror/array. It might be my memory, but I didn't think that ZFS was so considerate when replacing a failed drive with one that rounded to be a bit shorter.
 
You can solve the problem of mismatched drives though partitioning them, AnyRAID seems like overkill for that.

I don't know why ZFS doesn't just take a small amount off the size of the smallest device before doing its calculation.
 
cracauer@ said:
There is a webinar on this tomorrow if you want a fresh feed:
https://klarasystems.com/webinars/understanding-anyraid-architecture-use-cases-tradeoffs/
Click to expand...
My takeaways (mostly non-technical) and datapoints from the OP's referenced BSDCan 2026 presentation by Allan Jude, and additionally the Klara webinar, some of which have only been mentioned in the webinar:

Time frame implementation/integration in the OpenZFS repo and FreeBSD landing:
  • Pull requests implementations are pending in OpenZFS
  • This could become available for the next OpenZFS release ( ≠ next FreeBSD release )
  • It will probably will be in FreeBSD 16
  • When the OpenZFS AnyRAID will be in an OpenZFS release, it will likely already by applicable for the 15 branch of FreeBSD
  • It could be availble before the end of the year
Ofcourse, this is all subject to the succesful incorporation and acceptance by OpenZFS and, further down the line, FreeBSD.

Usage aspects:
  • AnyRAID is a seperate individual ZFS (vdev) type, to be selected at creation time*
  • AnyRAID seems to be the go-to solution for anyone who does not have an absolute emphasis to max squeeze out every last IOP that is to be had from the hardware (although there probably are some enterprise use cases that could benefit from AnyRAID, instances in the cloud were mentioned).
  • Contraction and expansion are two AnyRAID operations enabling to expand and contract an AnyRAID setup with individual disk(s); limited by the available space and the fixed stipe width. This means, for example, that a degraded AnyRAID vdev made up of 6 individual disks that suffers a 1 disk failure, can be transformed from a degraded state to a non-degraded state by contraction; the new AnyRAID vdev consists now of 5 disks with the expected redundancy.
Check it out yourself, it is already online:
Understanding AnyRAID: Architecture, Use-Cases, and Tradeoffs - Klara webinar by Allan Jude and Jon Panozzo.

___
* there might be a migration path somewhere in the future from RAIDZ to AnyRAID.
 
FWIW, I wanted to deploy AnyRaid to production yesterday, but it turns out they only implemented AnyMirror at this time, not Anyraidz<x>. I am still curious, but for that specific array the data just wouldn't fit in mirror mode.
 
cracauer@ said:
FWIW, I wanted to deploy AnyRaid to production yesterday, but it turns out they only implemented AnyMirror at this time, not Anyraidz<x>. I am still curious, but for that specific array the data just wouldn't fit in mirror mode.
Click to expand...
We did RAID-Z mode as well, it is a second pull request (still in code review though, no promises there won't be changes before the final version lands)
github.com

Anyraid phase 2; raidz, rebalance, and contraction by pcd1193182 · Pull Request #18406 · openzfs/zfs

Note: only the final 4 commits are part of this review, all previous commits are part of #17567 , which is a prerequisite for this PR. Sponsored by: Eshtek, creators of HexOS Sponsored by: Klara, I...
github.com github.com

It includes RAID-Z, "contract" (remove a disk from a RAID-Z as long as your RAID stripe is narrow enough), and "rebalance" to even out the free space across VDEVs.
 
hedwards said:
It's been a while since I tried, but I thought that only applied when creating a new mirror/array. It might be my memory, but I didn't think that ZFS was so considerate when replacing a failed drive with one that rounded to be a bit shorter.
Click to expand...
It depends if the rounding crosses that 16 GiB barrier
 
bob2112 said:
You can solve the problem of mismatched drives though partitioning them, AnyRAID seems like overkill for that.

I don't know why ZFS doesn't just take a small amount off the size of the smallest device before doing its calculation.
Click to expand...
ZFS does, but if you have 2x 8T disks, and 3x 12T disks, RAID-Z would lose you 12T of space. AnyRAID would let you keep most of that.
 
allanjude@ said:
We did RAID-Z mode as well, it is a second pull request (still in code review though, no promises there won't be changes before the final version lands)
github.com

Anyraid phase 2; raidz, rebalance, and contraction by pcd1193182 · Pull Request #18406 · openzfs/zfs

Note: only the final 4 commits are part of this review, all previous commits are part of #17567 , which is a prerequisite for this PR. Sponsored by: Eshtek, creators of HexOS Sponsored by: Klara, I...
github.com github.com

It includes RAID-Z, "contract" (remove a disk from a RAID-Z as long as your RAID stripe is narrow enough), and "rebalance" to even out the free space across VDEVs.
Click to expand...
Oh.

I didn't consider the phase2 branch because Paul made some commits on the phase1 that the phase2 branch has not been rebased to.

Thanks for the correction.
 
You must log in or register to reply here.
Back
Top