Review RAID-Z expansion for its capacity benefit without assuming a higher fault-tolerance level.
\nOpenZFS 2.3 supports attaching a device to a RAID-Z group to expand its capacity. The expansion reads allocated data and redistributes it across the enlarged group. It does not increase the number of device failures that the RAID-Z level can tolerate. If a device fails during expansion, expansion pauses until the group’s health is restored. Existing blocks retain their previous data-to-parity ratio, while new blocks use the expanded ratio. A pool-wide scrub follows completed expansion.
\nSource: OpenZFS 2.3 — zpool attach.
\nThis applies specifically to RAID-Z expansion documented for OpenZFS 2.3. It does not imply that earlier releases, appliance firmware, or every storage management interface supports the same procedure.
\nDSE recommends stating whether the objective is more usable capacity or a different fault-tolerance level before approving expansion. Record current pool health, independent recovery coverage, device identities, and the feature support of the actual deployment. Explain that old-block accounting may differ from a newly created wider group. Schedule supervision for a long-running operation and define the response if a disk fails. Keep the expansion and the concluding scrub in the same change record.
\nUse a representative test pool to observe expansion progress and the final scrub. Compare reported capacity with the original layout and the mix of old and new allocations. Confirm the team can explain the unchanged RAID-Z failure tolerance before accepting the production plan.
\nOpenZFS 2.3 — zpool attach. Reviewed October 15, 2026.
", "content_text": "Review RAID-Z expansion for its capacity benefit without assuming a higher fault-tolerance level.\nSource facts\nOpenZFS 2.3 supports attaching a device to a RAID-Z group to expand its capacity. The expansion reads allocated data and redistributes it across the enlarged group. It does not increase the number of device failures that the RAID-Z level can tolerate. If a device fails during expansion, expansion pauses until the group’s health is restored. Existing blocks retain their previous data-to-parity ratio, while new blocks use the expanded ratio. A pool-wide scrub follows completed expansion.\nSource: OpenZFS 2.3 — zpool attach.\nApplicability\nThis applies specifically to RAID-Z expansion documented for OpenZFS 2.3. It does not imply that earlier releases, appliance firmware, or every storage management interface supports the same procedure.\nDSE recommendation\nDSE recommends stating whether the objective is more usable capacity or a different fault-tolerance level before approving expansion. Record current pool health, independent recovery coverage, device identities, and the feature support of the actual deployment. Explain that old-block accounting may differ from a newly created wider group. Schedule supervision for a long-running operation and define the response if a disk fails. Keep the expansion and the concluding scrub in the same change record.\nVerification\nUse a representative test pool to observe expansion progress and the final scrub. Compare reported capacity with the original layout and the mix of old and new allocations. Confirm the team can explain the unchanged RAID-Z failure tolerance before accepting the production plan.\nOfficial reference\nOpenZFS 2.3 — zpool attach. Reviewed October 15, 2026.", "content_markdown": "Review RAID-Z expansion for its capacity benefit without assuming a higher fault-tolerance level.\n\n## Source facts\n\nOpenZFS 2.3 supports attaching a device to a RAID-Z group to expand its capacity. The expansion reads allocated data and redistributes it across the enlarged group. It does not increase the number of device failures that the RAID-Z level can tolerate. If a device fails during expansion, expansion pauses until the group’s health is restored. Existing blocks retain their previous data-to-parity ratio, while new blocks use the expanded ratio. A pool-wide scrub follows completed expansion.\n\nSource: [OpenZFS 2.3 — zpool attach](https://openzfs.github.io/openzfs-docs/man/v2.3/8/zpool-attach.8.html).\n\n## Applicability\n\nThis applies specifically to RAID-Z expansion documented for OpenZFS 2.3. It does not imply that earlier releases, appliance firmware, or every storage management interface supports the same procedure.\n\n## DSE recommendation\n\nDSE recommends stating whether the objective is more usable capacity or a different fault-tolerance level before approving expansion. Record current pool health, independent recovery coverage, device identities, and the feature support of the actual deployment. Explain that old-block accounting may differ from a newly created wider group. Schedule supervision for a long-running operation and define the response if a disk fails. Keep the expansion and the concluding scrub in the same change record.\n\n## Verification\n\nUse a representative test pool to observe expansion progress and the final scrub. Compare reported capacity with the original layout and the mix of old and new allocations. Confirm the team can explain the unchanged RAID-Z failure tolerance before accepting the production plan.\n\n## Official reference\n\n[OpenZFS 2.3 — zpool attach](https://openzfs.github.io/openzfs-docs/man/v2.3/8/zpool-attach.8.html). Reviewed October 15, 2026." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/keep-raid-z-fault-tolerance-separate-from-openzfs-expansion-capacity/", "url": "https://update.dsesecurity.com/updates/keep-raid-z-fault-tolerance-separate-from-openzfs-expansion-capacity/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-15" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/keep-raid-z-fault-tolerance-separate-from-openzfs-expansion-capacity/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Keep RAID-Z fault tolerance separate from OpenZFS expansion capacity", "item": "https://update.dsesecurity.com/updates/keep-raid-z-fault-tolerance-separate-from-openzfs-expansion-capacity/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/keep-raid-z-fault-tolerance-separate-from-openzfs-expansion-capacity/#article", "identifier": "https://update.dsesecurity.com/updates/keep-raid-z-fault-tolerance-separate-from-openzfs-expansion-capacity/", "url": "https://update.dsesecurity.com/updates/keep-raid-z-fault-tolerance-separate-from-openzfs-expansion-capacity/", "headline": "Keep RAID-Z fault tolerance separate from OpenZFS expansion capacity", "description": "Review RAID-Z expansion for its capacity benefit without assuming a higher fault-tolerance level.", "abstract": "Review RAID-Z expansion for its capacity benefit without assuming a higher fault-tolerance level.", "articleBody": "Review RAID-Z expansion for its capacity benefit without assuming a higher fault-tolerance level.\nSource facts\nOpenZFS 2.3 supports attaching a device to a RAID-Z group to expand its capacity. The expansion reads allocated data and redistributes it across the enlarged group. It does not increase the number of device failures that the RAID-Z level can tolerate. If a device fails during expansion, expansion pauses until the group’s health is restored. Existing blocks retain their previous data-to-parity ratio, while new blocks use the expanded ratio. A pool-wide scrub follows completed expansion.\nSource: OpenZFS 2.3 — zpool attach.\nApplicability\nThis applies specifically to RAID-Z expansion documented for OpenZFS 2.3. It does not imply that earlier releases, appliance firmware, or every storage management interface supports the same procedure.\nDSE recommendation\nDSE recommends stating whether the objective is more usable capacity or a different fault-tolerance level before approving expansion. Record current pool health, independent recovery coverage, device identities, and the feature support of the actual deployment. Explain that old-block accounting may differ from a newly created wider group. Schedule supervision for a long-running operation and define the response if a disk fails. Keep the expansion and the concluding scrub in the same change record.\nVerification\nUse a representative test pool to observe expansion progress and the final scrub. Compare reported capacity with the original layout and the mix of old and new allocations. Confirm the team can explain the unchanged RAID-Z failure tolerance before accepting the production plan.\nOfficial reference\nOpenZFS 2.3 — zpool attach. Reviewed October 15, 2026.", "datePublished": "2026-10-15T13:32:45+00:00", "dateModified": "2026-10-15T13:36:15+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/keep-raid-z-fault-tolerance-separate-from-openzfs-expansion-capacity/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/keep-raid-z-fault-tolerance-separate-from-openzfs-expansion-capacity/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Keep RAID-Z fault tolerance separate from OpenZFS expansion capacity" }, "articleSection": [ "Business Continuity", "IT" ], "keywords": [ "Business Continuity", "IT", "Guide", "Information priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "wordCount": 247, "timeRequired": "PT2M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "OpenZFS 2.3 — zpool attach", "url": "https://openzfs.github.io/openzfs-docs/man/v2.3/8/zpool-attach.8.html" } } ] } }