June 2021 FreeBSD Developer Summit: Raid-Z Expansion
FreeBSD2 HN recommenders · recommended in 2 months, 2021–2023
talk · advanced · 2021–2023 on HN
Matt Ahrens presents the FreeBSD Foundation sponsored RAID-Z Expansion project for ZFS at the June 2021 FreeBSD Developer Summit. It explains how a RAID-Z vdev can be grown by adding disks on the fly.
HN points to it as the video explanation of how RAID-Z expansion works without block pointer rewrite.
Up next
11 mo on HN"Testing Distributed Systems w/ Deterministic Simulation" by Will Wilson
Strange Loop Conference
12 HN recommender · 2014–2024
11 mo on HNThe Value of Values with Rich Hickey
InfoQ
10 HN recommender · 2014–2023
9 mo on HNAWS re:Invent 2018: Amazon DynamoDB Deep Dive: Advanced Design Patterns for DynamoDB (DAT401)
Amazon Web Services
12 HN recommender · 2019–2025
9 mo on HN"Turning the database inside out with Apache Samza" by Martin Kleppmann
Strange Loop Conference
9 HN recommender · 2015–2025
7 mo on HNConflict Resolution for Eventual Consistency • Martin Kleppmann • GOTO 2016
GOTO Conferences
3 HN recommender · 2017–2020
6 mo on HN01 - Course Introduction & Relational Model (CMU Databases Systems / Fall 2019)
CMU Database Group
6 HN recommender · 2020–2023
6 mo on HNIntroduction to NoSQL • Martin Fowler • GOTO 2012
GOTO Conferences
6 HN recommender · 2015–2021
5 mo on HNRich Hickey rants about HttpServletRequest in 1080p: Death By Specificity from Clojure Made Simple
Fred Overflow
5 HN recommender · 2020–2026
6 mo on HNTigerStyle! (Or How To Design Safer Systems in Less Time) by Joran Dirk Greef
TigerBeetle
2 HN recommender · 2023–2025
5 mo on HNBryan Cantrill from Joyent on Manta: internet-facing object storage facility that features compute
AI Council
4 HN recommender · 2014–2026
5 mo on HNMichael Stonebraker | Big Data is (at least) Four Different Problems
Michigan Engineering
5 HN recommender · 2015–2024
5 mo on HN"I See What You Mean" by Peter Alvaro
Strange Loop Conference
6 HN recommender · 2016–2019
3 comments from Hacker News
That is not how this will work. The reason the parity ratio stays the same, is that all of the references to the data are by DVA (Data Virtual Address, effectively the LBA within the RAID-Z vdev). So the data will occupy the same amount of space and parity as it did before. All stripes in RAID-Z are dynamic, so if your stripe is 5 wide and your array is 6 wide, the 2nd stripe will start on the last disk and wrap around. So if your 5x10 TB disks are 90% full, after the expansion they will contain the same 5.4 TB of data and 3.6 TB of parity, and the pool will now be 10 TB bigger. New writes, will be 4+2 instead, but the old data won't change (they is how this feature is able to work without needing block-pointer rewrite). See this presentation: ▶ this video
For those that like videos more than text, there is a youtube video from last year [1] that explain the feature (unless it's changed since ,but it seems not to be the case). One downside that I see of this approach, if I understand it correctly, is that the data already present on disk will not take advantage of the extra disk per slice. For example, if I have a raidz of 4 disks (so 25% of space "wasted"), and add another disk, new data will be distributed on 5 disks (so 20% of space "wasted") but the old data will keep using stripes of 4 blocks, they will just be reshuffled between the disks. Do I understand it correctly ? [1] ▶ this video
> AFAIK ZFS pools can't easily be resized > you generally have to recreate them Not anymore. There is RAIDZ Expansion available. Happens on the fly. - ▶ this video - link