> For the complete documentation index, see [llms.txt](https://book.bsdcn.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://book.bsdcn.org/zfs/ji-chu-gai-nian/cun-chu-chi-jie-gou-pool-structure/raidz.md).

# RAIDZ (ZFS RAID)

## 介绍

RAIDZ 是 RAID-5 的一种变体，它能更好地分布校验，并消除了 RAID-5 的“写入漏洞”（断电后数据与校验信息不一致）。数据和校验会在 raidz 组内的所有磁盘上进行条带化分布。

一个 raidz 组可以有单重、双重或三重校验，这意味着该 raidz 组可以在不丢失任何数据的情况下，分别承受一次、两次或三次设备故障。`raidz1` vdev 类型表示单重校验的 raidz 组；`raidz2` vdev 类型表示双重校验的 raidz 组；`raidz3` vdev 类型表示三重校验的 raidz 组。`raidz` vdev 类型是 raidz1 的别名。

一个由 N 个大小为 X 的磁盘组成、具有 P 个校验盘的 raidz 组，大约可以存储 (N-P)\*X 字节的数据，并能在 P 个设备故障时仍不丢失数据。raidz 组中设备的最少数量为校验盘数量加一。推荐数量为 3 到 9 个，可帮助提升性能。

## 空间效率

RAIDZ 中块的实际使用空间取决于以下几个因素：

* 最小写入单位为磁盘扇区大小（可通过 vdev 参数 `ashift` 设置）
* RAIDZ 的条带宽度是动态的，至少包含一个数据块部分，最多为磁盘数量减去校验数量个数据块部分
* 一个大小为 `recordsize` 的数据块会按扇区大小平均拆分，并写入 RAIDZ vdev 的每个条带
* 每个数据条带都会包含数据块的一部分
* 除数据块外，还需写入一、二或三块校验块，每块对应一个磁盘；例如，5 个磁盘的 raidz2 将有 3 块数据和 2 块校验

基于这些因素，如果 `recordsize` 小于或等于扇区大小，则 RAIDZ 的校验大小实际上等同于具有相同冗余的镜像。例如，对于 3 个磁盘、`ashift=12`、`recordsize=4K` 的 raidz1，我们在磁盘上会分配：

* 一块 4K 数据块
* 一块 4K 校验块

可用空间比例为 50%，与双镜像相同。

另一个例子，3 个磁盘的 raidz1，`ashift=12`，`recordsize=128K`：

* 条带总宽度为 3
* 每条带最多可有 2 个 4K 的数据块部分，因为有 1 块校验块
* 128K / 8K = 16 条带，每条带有 8K 数据和 4K 校验
* 16 个条带，每个条带写入 12K，即写入 192K 才能存储 128K 数据

此情况下可用空间比例为 66%。

RAIDZ 的磁盘越多，条带越宽，空间效率越高。

每种 RAIDZ 大小的实际校验开销可在此查看：[RAIDZ 校验开销表](https://docs.google.com/spreadsheets/d/e/2PACX-1vRDgvK_cjwpLZBQcneGIS2cmEExUgqUQPblUmGGVXgG1zt-2YR3INFiWMMuYnbo5bK94t1aYGbtoLCS/pubhtml)（[数据源](https://docs.google.com/spreadsheets/d/1_CO8x03VICdiIMulDjQi9NDBd53qFpUreMQVrF1uS28/edit?usp=sharing)）。

## 性能考虑

### 写入

一个条带跨越阵列中的所有磁盘。一次块写入会将条带部分写入每个磁盘。在最坏情况下，RAIDZ vdev 的写入 IOPS 等于阵列中最慢磁盘的 IOPS，因为所有条带部分的写入操作必须在每个磁盘上完成。

### 读取

一次读取只涉及该块实际占用的列，而不是整个组。一个由 `N` 个扇区组成、未填满整行条带的块，会分布到 `N` 个数据列上，组的其余部分不受影响。健康状态下的读取完全不会读取校验，只有在数据缺失时，或在 scrub、resilver 期间才会取用校验。

因此，决定读取行为的不是 vdev 的宽度，而是块大小与条带宽度的比值：

* 当块跨越 **所有** 数据列时（这是常见情况，默认 `recordsize` 为 128 KiB，足以填满任何现实规模的组），每次读取都要在每个数据盘上产生一次 I/O。此时无论组有多宽，随机读 IOPS 都大致相当于单块磁盘。
* 当块相对组而言 **较小** 时（例如在宽 vdev 上运行 `recordsize=8K` 或 `16K` 的数据库），每次读取只落在少数几块磁盘上，对不同块的并发读取可以并行进行。这种情况下 IOPS 确实会随规模提升，代价是小记录在 RAIDZ 上极差的空间效率（见上文）。

两种情况下，流式带宽都随数据盘数量提升。

因此，“RAIDZ 只能提供单块磁盘的 IOPS”这一经验法则针对的是默认的大记录配置，而非 RAIDZ 本身的特性。对于通用存储池，这仍是合理的假设；当随机读 IOPS 成为瓶颈时，镜像依然是更好的选择。

#### 一块慢盘

读取只有在其跨越的所有列都返回后才算完成，因此延迟取决于其中最慢的一块磁盘。于是一块有故障征兆的磁盘就能拖垮整个组（[#9375](https://github.com/openzfs/zfs/issues/9375)）。

自 OpenZFS 2.4 起，这种情况可以被检测并规避：持续缓慢的子 vdev 会进入 *sit out*（暂停参与）状态，在此期间读取会跳过它，并从校验重建其数据。写入仍会发往该盘，因此冗余得以维持，scrub 也始终读取它。同一时刻最多可有 `nparity` 块磁盘处于 sit out 状态。该时长由 `vdev_read_sit_out_secs` 设置（默认 600 秒，设为 `0` 则完全关闭检测）。每次进入 sit out 都会增加该 vdev 的 `slow_ios` 计数，并发出一个 `ereport.fs.zfs.delay` 事件。

## 扩容

raidz vdev 可以通过附加另一块设备来扩容：

```sh
zpool attach pool raidz2-0 sdX
```

容错能力保持不变（RAID-Z2 仍是 RAID-Z2），扩容前写入的块保持原有的数据与校验比例，只是分布到更多磁盘上；只有新写入的块才使用更宽的比例。参见[更改存储池布局](/zfs/ji-chu-gai-nian/cun-chu-chi-jie-gou-pool-structure/changing-pool-layout.md)。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://book.bsdcn.org/zfs/ji-chu-gai-nian/cun-chu-chi-jie-gou-pool-structure/raidz.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.