现在Zstd 正在慢慢地得到浏览器的支持，我想知道我是否可以保留我的 Zstd 压缩并像 ZFS 一样转发文件。
据我所知，目前 ZFS 会在我的 Web 服务器处理 Zstd 压缩文件之前对其进行隐式解压缩，并且 Web 服务器需要再次压缩它们才能将它们发送给用户。
有没有办法将这些文件直接传递到 Web 服务器而无需来回压缩？
我很可能会使用 nginx 或 caddy 来提供这些文件，但我感兴趣的是是否有办法在 Linux 上运行的任何软件（例如 python 或 nodejs 或 ruby 或 php）中访问文件的压缩版本。
我有一台 Proxmox 服务器，上面有几个 zpool。其中一个 zpoolrust01是 4 磁盘 zpool，其中元数据和写入缓存是主板上的一些 nvme m.2 驱动器（每个驱动器一个 - 我知道，这很愚蠢，但这就是所做的）。
看起来好像rust01发生了灾难性故障。当我在服务器视图中单击时rust01，出现以下错误：
could not activate storage 'rust01', zfs error: cannot import 'rust01': I/O error (500)
当我转到{服务器}>磁盘>ZFS时，我看不到zpool rust01。
当我转到{服务器}>磁盘时，我甚至看不到 4 个磁盘或特殊元数据文件或读/写缓存驱动器。
当我跑步时zpool status -x我得到all pools are healthy
当我运行时，zpool import rust01我收到以下消息：
cannot import 'rust01': I/O error
Destroy and re-create the pool from
a backup source.
当我运行时，zpool status rust01我得到cannot open 'rust01': no such pool，当我重新启动服务器时，下面是通过电子邮件发送给我的错误：
ZFS has detected that a device was removed.
impact: Fault tolerance of the pool may be compromised.
eid: 10
class: statechange
state: UNAVAIL
host: pve01
time: 2024-09-14 21:20:32-0500
vpath: /dev/nvme2n1p1
vphys: pci-0000:41:00.0-nvme-1
vguid: 0x297D516B1F1D6494
devid: nvme-Samsung_SSD_970_EVO_Plus_2TB_S6S2NS0T815592K-part1
pool: rust01 (0xE4AAC2680D8B6A7E)
当我运行时，zpool destroy rust01我收到以下错误cannot open 'rust01': no such pool。理想情况下，我希望rust01重新上线。我相当确定问题是上述电子邮件中提到的特殊元数据磁盘。话虽如此，我很乐意销毁并重新创建rust01。该磁盘上的所有虚拟机都已备份，因此我可以轻松恢复（如果需要）。但是，我的问题是，我找不到让 Proxmox/ZFS 释放与损坏的 zpool 关联的磁盘的方法rust01。以下是的输出lsblk：
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 1 465.8G 0 disk
|-sda1 8:1 1 1007K 0 part
|-sda2 8:2 1 1G 0 part
`-sda3 8:3 1 464G 0 part
sdb 8:16 1 465.8G 0 disk
|-sdb1 8:17 1 1007K 0 part
|-sdb2 8:18 1 1G 0 part
`-sdb3 8:19 1 464G 0 part
sdc 8:32 1 3.6T 0 disk
|-sdc1 8:33 1 3.6T 0 part
`-sdc9 8:41 1 8M 0 part
sdd 8:48 1 3.6T 0 disk
|-sdd1 8:49 1 3.6T 0 part
`-sdd9 8:57 1 8M 0 part
sde 8:64 1 3.6T 0 disk
|-sde1 8:65 1 3.6T 0 part
`-sde9 8:73 1 8M 0 part
sdf 8:80 1 3.6T 0 disk
|-sdf1 8:81 1 3.6T 0 part
`-sdf9 8:89 1 8M 0 part
sdg 8:96 1 0B 0 disk
sdh 8:112 1 0B 0 disk
sdi 8:128 1 0B 0 disk
sdj 8:144 1 0B 0 disk
sdk 8:160 1 0B 0 disk
sdl 8:176 1 0B 0 disk
sdm 8:192 1 0B 0 disk
sdn 8:208 1 0B 0 disk
sr0 11:0 1 1024M 0 rom
sr1 11:1 1 1024M 0 rom
sr2 11:2 1 1024M 0 rom
sr3 11:3 1 1024M 0 rom
zd0 230:0 0 4M 0 disk
zd16 230:16 0 80G 0 disk
`-zd16p1 230:17 0 80G 0 part
zd32 230:32 0 64G 0 disk
|-zd32p1 230:33 0 1M 0 part
|-zd32p2 230:34 0 2G 0 part
`-zd32p3 230:35 0 62G 0 part
zd48 230:48 0 40G 0 disk
|-zd48p1 230:49 0 600M 0 part
|-zd48p2 230:50 0 1G 0 part
`-zd48p3 230:51 0 38.4G 0 part
zd64 230:64 0 32G 0 disk
|-zd64p1 230:65 0 31G 0 part
|-zd64p2 230:66 0 1K 0 part
`-zd64p5 230:69 0 975M 0 part
zd80 230:80 0 90G 0 disk
|-zd80p1 230:81 0 100M 0 part
|-zd80p2 230:82 0 16M 0 part
|-zd80p3 230:83 0 89.4G 0 part
`-zd80p4 230:84 0 523M 0 part
zd96 230:96 0 90G 0 disk
|-zd96p1 230:97 0 499M 0 part
|-zd96p2 230:98 0 128M 0 part
|-zd96p3 230:99 0 88.5G 0 part
`-zd96p4 230:100 0 920M 0 part
zd112 230:112 0 100G 0 disk
|-zd112p1 230:113 0 499M 0 part
|-zd112p2 230:114 0 99M 0 part
|-zd112p3 230:115 0 16M 0 part
`-zd112p4 230:116 0 99.4G 0 part
zd128 230:128 0 64G 0 disk
|-zd128p1 230:129 0 1M 0 part
|-zd128p2 230:130 0 2G 0 part
`-zd128p3 230:131 0 62G 0 part
zd144 230:144 0 90G 0 disk
|-zd144p1 230:145 0 500M 0 part
`-zd144p2 230:146 0 89.5G 0 part
zd160 230:160 0 60G 0 disk
|-zd160p1 230:161 0 100M 0 part
|-zd160p2 230:162 0 16M 0 part
|-zd160p3 230:163 0 59.4G 0 part
`-zd160p4 230:164 0 450M 0 part
zd176 230:176 0 32G 0 disk
|-zd176p1 230:177 0 1M 0 part
|-zd176p2 230:178 0 2G 0 part
`-zd176p3 230:179 0 30G 0 part
zd192 230:192 0 100G 0 disk
|-zd192p1 230:193 0 450M 0 part
|-zd192p2 230:194 0 99M 0 part
|-zd192p3 230:195 0 15.8M 0 part
|-zd192p4 230:196 0 89.4G 0 part
`-zd192p5 230:197 0 256K 0 part
zd208 230:208 0 32G 0 disk
|-zd208p1 230:209 0 600M 0 part
|-zd208p2 230:210 0 1G 0 part
`-zd208p3 230:211 0 30.4G 0 part
zd224 230:224 0 1M 0 disk
nvme1n1 259:0 0 1.8T 0 disk
|-nvme1n1p1 259:1 0 1.8T 0 part
`-nvme1n1p9 259:2 0 8M 0 part
nvme3n1 259:3 0 1.8T 0 disk
|-nvme3n1p1 259:4 0 1.8T 0 part
`-nvme3n1p9 259:5 0 8M 0 part
nvme0n1 259:6 0 1.8T 0 disk
|-nvme0n1p1 259:7 0 1.8T 0 part
`-nvme0n1p9 259:8 0 8M 0 part
nvme2n1 259:9 0 1.8T 0 disk
|-nvme2n1p1 259:10 0 1.8T 0 part
`-nvme2n1p9 259:11 0 8M 0 part
此主机上还有其他虚拟机在其他 zpool 上运行，看起来运行良好。因此，重新安装所有内容不是我想要的选择。
更新：在执行使用电源循环方法修复损坏的 SSD中概述的步骤后，4TB 硬盘出现在 Proxmox 中，尽管 zpool 无法访问。取得了一些进展，但仍然无法访问数据。
除了擦除受影响的 zpool 中的磁盘之外，还有什么其他想法吗？
我有一个由两个驱动器组成的镜像配置的 ZPool。似乎在服务器维护（清理）期间，其中一个驱动器由于接线松动而离线。
# zpool status -v zmsmall1
pool: zmsmall1
state: DEGRADED
status: One or more devices could not be used because the label is missing or
invalid. Sufficient replicas exist for the pool to continue
functioning in a degraded state.
action: Replace the device using 'zpool replace'.
see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-4J
scan: scrub repaired 0B in 02:00:24 with 0 errors on Sun Apr 14 02:24:25 2024
config:
NAME STATE READ WRITE CKSUM
zmsmall1 DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
ata-ST1000NM0033-9ZM173_Z1W074QR ONLINE 0 0 0
16687432235547222567 UNAVAIL 0 0 0 was /dev/disk/by-id/ata-TOSHIBA_MG03ACA100_93S2K8CZF-part1
errors: No known data errors
不幸的是，没有关于该问题的通知。4 天后，我发现了问题，现在我对如何继续进行产生了怀疑。我担心的是，在线驱动器在过去几天一直在接收数据，并且偏离了第二个驱动器的状态。我担心简单地恢复第二个驱动器并发出一个zpool clear zmsmall1可能会弄乱第一个驱动器上的好数据。
我应该如何进行安全恢复？PS：我已经在进行第二次备份，但我更愿意解决这个问题（用于练习），而不是建立一个新的池。
我不小心将不匹配的 raidz1 添加到现有池中。是的，我指定了“-f”来执行此操作，但我希望出于不同的原因使用“-f”，但没有注意。
无论如何...有多糟糕？我真的只是需要泳池中有额外的空间，并且希望该空间是多余的。泳池看起来像这样：
NAME STATE READ WRITE CKSUM
pool_02c ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
c0t5000C500B4AA5681d0 ONLINE 0 0 0
c0t5000C500B4AA6A51d0 ONLINE 0 0 0
c0t5000C500B4AABF20d0 ONLINE 0 0 0
c0t5000C500B4AAA933d0 ONLINE 0 0 0
raidz1-1 ONLINE 0 0 0
c0t5000C500B0889E5Bd0 ONLINE 0 0 0
c0t5000C500B0BCFB13d0 ONLINE 0 0 0
c0t5000C500B09F0C54d0 ONLINE 0 0 0
我读到了关于这种情况的另一个问题，它指出“性能和空间效率（即：通过非最佳填充）都会受到影响”，但这有点模糊，我希望有人能提供更多信息细节。
从池使用的角度来看，放在 vdev raidz1-0 中的磁盘上的数据在该 vdev 中不是冗余的，而放入 raidz1-1 中的数据在该 vdev 中不是冗余的吗？而且，如果是这样的话，性能难道不会与特定的 vdev 相关吗？
填充在这里发挥作用，这将如何影响存储容量？IE。是否会导致分配更多空间，就像我每写入 1M，就用掉 1.2M？
我并不太关心这个池的性能，但是这个配置如何影响读/写速度？我希望每个 vdev 都能以其各自设备的速度执行，那么 vdev 复制差异如何影响这一点？
仅供参考，这是在 Solaris 11.4 系统上。我尝试使用以下方法删除 vdev：
zpool remove pool_02c raidz1-1
但我收到错误：
cannot remove device(s): not enough space to migrate data
这看起来很奇怪，因为我实际上只是添加了它并且没有向池中写入任何内容。
我可以接受它，因为它似乎给了我我所期望的空间，但我只是想更好地理解我将与之共处的魔鬼。
我在 Ubuntu 下有一个长期运行的 ZFS 池，它已经经历了多次升级。从 Ubuntu 20 升级到 22 后，加密的文件系统拒绝挂载，但其余的似乎都正常。 在加密文件系统的根部zpool status -v报告永久错误ZFS-8000-8A 。我注意到 zfsutils-linux 的软件包版本从 0.8.3 到 2.1.5 有一个很大的跳跃。
该池仍然可以导入到 Ubuntu 20 系统，并且加密的文件系统仍然可以安装在那里。看起来还不错。更重要的是，我可以zfs send在 Ubuntu 20 和zfs receiveUbuntu 22 上进行操作，并取得了明显的成功。
如果我将zfs send整个池（或部分操作）从 Ubuntu 20 (ZFS 0.8.3) 升级到 Ubuntu 22 (ZFS 2.1.5) 并且操作成功，我是否会创建一个没有升级问题的池？也就是说，接收操作是否会构建一个与 ZFS 完全同步的池？或者链接是否会出现兼容性问题？
我对 zfs 发送/接收操作的级别了解不够，无法确保在 Ubuntu 22 下不会出现进一步的损坏。
如果有必要，我很乐意重新加密加密的文件系统，而不是发送原始文件。一切都将在本地发生。在本例中，Ubuntu 20 在连接了磁盘设备的 LXD VM 中运行，并且发送/接收管道不跨越任何网络。
请注意，我知道废弃整个池并从备份中恢复它的建议。我正在尝试恢复而不必诉诸于此，因为我似乎能够读取池。
所有磁盘都通过了长时间的 SMART 测试，并且在 Ubuntu 20 下清理池没有显示任何错误。
我很高兴被告知（带有引用）该错误仅限于加密文件系统，我可以替换它们并继续，而无需重建整个池，但我对 ZFS 内部结构了解不够，无法确定那。我很想知道如何找到答案。
我已经在我的 ZFS 池上设置了定期清理，并开始考虑时不时地设置智能检查，但我对一个条目有清晰的记忆，我无法发现不应安排重叠时间。在安排时是否应该考虑任何此类考虑因素，例如清理、重新同步和智能检查？清理和重新同步似乎很明显，但是在其他磁盘维护操作之间呢？虽然我读到一些关于在多个池上不重叠清理的讨论，但在对 raid 阵列运行智能检查并在同一系统中的池上运行清理时是否应该考虑这一点？
只是一个简单的理解问题。我有一台 TrueNas Scale 服务器，我刚刚将加密方法从密钥更改为密码。现在我想知道是否需要重写整个数据集才能应用此功能？我的数据现在在磁盘上是未加密的还是使用旧密钥的？感谢您的帮助 ：）
我正在尝试对全 NVMe ZFS 磁盘阵列进行基准测试。我熟悉极快的基准测试结果，由于高效的 ZFS 缓存，磁盘活动非常少。我遇到了相反的情况：大量的 ZFS 磁盘活动，但 FIO 仅显示很少的带宽。我该如何解释这种行为？
Zpool iostat -v 1仅显示一秒，但每秒输出一致：16 至 20 GiB/s 写入带宽
capacity operations bandwidth
pool alloc free read write read write
------------ ----- ----- ----- ----- ----- -----
my_pool-10 1.92T 19.0T 2 155K 95.7K 16.9G
mirror-0 329G 3.16T 0 26.2K 3.99K 2.84G
nvme2n1 - - 0 13.2K 0 1.42G
nvme3n1 - - 0 13.1K 3.99K 1.42G
mirror-1 328G 3.16T 0 26.0K 0 2.83G
nvme4n1 - - 0 13.0K 0 1.41G
nvme5n1 - - 0 13.0K 0 1.41G
mirror-2 329G 3.16T 0 25.8K 0 2.83G
nvme6n1 - - 0 12.9K 0 1.42G
nvme7n1 - - 0 12.8K 0 1.42G
mirror-3 328G 3.16T 0 25.8K 3.99K 2.81G
nvme8n1 - - 0 12.9K 3.99K 1.40G
nvme9n1 - - 0 12.9K 0 1.40G
mirror-4 328G 3.16T 0 26.0K 87.7K 2.82G
nvme10n1 - - 0 13.0K 87.7K 1.41G
nvme11n1 - - 0 13.0K 0 1.41G
mirror-5 327G 3.16T 0 25.6K 0 2.82G
nvme12n1 - - 0 12.9K 0 1.41G
nvme13n1 - - 0 12.8K 0 1.41G
------------ ----- ----- ----- ----- ----- -----
据我了解，该表中的写入统计数据增加了一倍。顶部的 16.9G 写入计数所有设备上的写入。由于这些是镜像 vdev，因此其中只有一半是“数据”，另一半是冗余。显然，仍然存在一些开销。从这个意义上说，我预计我的带宽将从 16.9GB/s 下降到 8.45GB/s，再到大约 6.75GB/s（20% 开销）
另一方面，我的 FIO 基准测试显示约为 240MiB/s。要么我不理解输出，要么有什么东西占用了我的带宽。
我运行 25 个 4k 写入的并行作业（测试烦人的网络负载）。命令是：
sync; fio --name=asyncio --ioengine=posixaio --rw=randwrite --bs=4k --fsync=1 --size=100g --numjobs=25 --iodepth=64 --runtime=60 --time_based --filename=/my_pool-10/unbuffwrite2 --group_reporting
asyncio: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=posixaio, iodepth=64
...
fio-3.28
Starting 25 processes
asyncio: Laying out IO file (1 file / 102400MiB)
Jobs: 25 (f=25): [w(25)][100.0%][w=240MiB/s][w=61.4k IOPS][eta 00m:00s]
asyncio: (groupid=0, jobs=25): err= 0: pid=33672: Sat Aug 26 20:20:18 2023
write: IOPS=61.2k, BW=239MiB/s (251MB/s)(14.0GiB/60015msec); 0 zone resets
slat (nsec): min=90, max=5052.1k, avg=810.57, stdev=5386.98
clat (usec): min=52, max=47390, avg=9496.96, stdev=6324.85
lat (usec): min=53, max=47392, avg=9497.77, stdev=6324.94
clat percentiles (usec):
| 1.00th=[ 2442], 5.00th=[ 2835], 10.00th=[ 3195], 20.00th=[ 3785],
| 30.00th=[ 4555], 40.00th=[ 5866], 50.00th=[ 7635], 60.00th=[ 9765],
| 70.00th=[12256], 80.00th=[15139], 90.00th=[18744], 95.00th=[21890],
| 99.00th=[27395], 99.50th=[29754], 99.90th=[34341], 99.95th=[36439],
| 99.99th=[40633]
bw ( KiB/s): min=211040, max=272704, per=100.00%, avg=244851.53, stdev=462.61, samples=2975
iops : min=52760, max=68176, avg=61212.84, stdev=115.66, samples=2975
lat (usec) : 100=0.01%, 250=0.01%, 500=0.01%, 750=0.01%, 1000=0.01%
lat (msec) : 2=0.06%, 4=23.36%, 10=37.74%, 20=31.19%, 50=7.64%
fsync/fdatasync/sync_file_range:
sync (usec): min=267, max=53554, avg=16564.62, stdev=7006.70
sync percentiles (usec):
| 1.00th=[ 3589], 5.00th=[ 5145], 10.00th=[ 6849], 20.00th=[ 9896],
| 30.00th=[12518], 40.00th=[14877], 50.00th=[16909], 60.00th=[18482],
| 70.00th=[20317], 80.00th=[22414], 90.00th=[25297], 95.00th=[27919],
| 99.00th=[33817], 99.50th=[35914], 99.90th=[40109], 99.95th=[42206],
| 99.99th=[44827]
cpu : usr=0.99%, sys=0.26%, ctx=916290, majf=0, minf=702924
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=1.9%, 16=11.8%, 32=161.4%, >=64=25.1%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=95.3%, 8=1.4%, 16=1.6%, 32=1.1%, 64=0.6%, >=64=0.0%
issued rwts: total=0,3672021,0,3683331 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=64
Run status group 0 (all jobs):
WRITE: bw=239MiB/s (251MB/s), 239MiB/s-239MiB/s (251MB/s-251MB/s), io=14.0GiB (15.0GB), run=60015-60015msec
关于我的带宽去了哪里有什么见解吗？
首先：我完全可以接受目前的情况，并且不是在寻找立即的解决方案，而是试图了解此约束的技术限制。
我主要在 Linux 上使用 ZFS，但我的理解是，所有 FOSS ZFS 开发现在都植根于 OpenZFS，因此任何/所有其变体的信息都值得赞赏。
仅当主池存储不包含顶级 raidz vdev、所有顶级 vdev 具有相同扇区大小并且加载所有加密数据集的密钥时，才能删除顶级 vdev。
我理解和/或可以猜测大多数这些限制的原因，但我并不真正理解为什么仅仅存在raidz vdev 就会阻止删除任何（甚至是镜像或非冗余）vdev。
我的理解/假设是，从池的角度来看，每个 vdev 充当“哑块设备”，实际的冗余/镜像发生在 vdev 级别（正如池级别没有冗余的重复警告所暗示的那样：所有vdev 级别必须存在冗余，单个 vdev 发生故障会导致整个池停机）。
在这种假设下，删除什么特定数据 vdev 并不重要，更不用说池中存在“坏”(raidz) vdev 。
显然，这种假设（或我想不到的其他假设）是错误的。有人可以启发我什么吗？
我唯一无法验证的猜测是，raidz vdevs 没有绝对原因阻止 vdev 删除，但是某些 raidz 特定操作和设备删除之间的某些交互根本没有实现/测试/至此已验证。
我在 4 个 HDD 的 zfspool 上安装了 Debian 系统（例如两个 raid1 的 raid10 - raid0）。显示为 2 个镜像（mirror0 和mirror1）的集合，每个镜像都有 2 个 HDD。
其中一个磁盘出现故障。由于该服务器中没有更多的空闲插槽，我通过命令将其分离：
zpool detach poolname diskname
然后将其物理拔下，然后插入新的。现在 zpool 看起来像这样：
zpool status rpool
pool: rpool
state: ONLINE
scan: scrub repaired 52K in 0 days 08:33:06 with 0 errors on Sun May 9 08:57:09 2021
config:
NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ata-TOSHIBA_HDWQ140_104EK2MQFAYG-part3 ONLINE 0 0 0
ata-TOSHIBA_HDWQ140_1042K0ECFAYG-part3 ONLINE 0 0 0
ata-TOSHIBA_HDWQ140_104EK2MLFAYG ONLINE 0 0 0
看来已经不是raid10了 我无法用新磁盘更换有故障的磁盘：
zpool replace rpool 4504484537486819887 /dev/disk/by-id/newdisk_id
cannot replace 4504484537486819887 with /dev/disk/by-id/newdisk_id: no such device in pool
将新磁盘添加到池并恢复池配置的安全方法是什么？