主页 / server / 问题

问题[zfs](server)

Martin Hope
Josh
Asked: 2024-12-30 00:10:52 +0800 CST
  • 6

使用带有 ZFS 存储池的 proxmox，是否可以将 LXC 容器或 QEMU 虚拟机恢复到早期快照（而不是最新快照）而不会丢失或破坏任何快照？

尝试使用 Proxmox GUI 执行此操作会显示一条错误消息：

无法回滚，“snapshotname”不是“storage:vmname”上的最新快照

换个角度问，是否有可能出现非线性快照？例如，快照树看起来像这样，其中有一个带有分支的真正“树”，并且一些快照有多个子节点？

屏幕截图显示根级别“创建”快照有两个子快照：“initial”和“wip-working-qemu”，并且它们都有独立的快照树。

互联网上的多个来源似乎表明不是这样（示例 1或示例 2），但我知道这是不正确的，因为我已经这样做了 :)

zfs
Martin Hope
Onni Hakala
Asked: 2024-09-20 02:22:07 +0800 CST
  • 6

现在Zstd 正在慢慢地得到浏览器的支持，我想知道我是否可以保留我的 Zstd 压缩并像 ZFS 一样转发文件。

据我所知，目前 ZFS 会在我的 Web 服务器处理 Zstd 压缩文件之前对其进行隐式解压缩，并且 Web 服务器需要再次压缩它们才能将它们发送给用户。

有没有办法将这些文件直接传递到 Web 服务器而无需来回压缩？

我很可能会使用 nginx 或 caddy 来提供这些文件，但我感兴趣的是是否有办法在 Linux 上运行的任何软件（例如 python 或 nodejs 或 ruby​​ 或 php）中访问文件的压缩版本。

zfs
Martin Hope
user1913559
Asked: 2024-09-15 19:01:04 +0800 CST
  • 5

我有一台 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 中的磁盘之外，还有什么其他想法吗？

zfs
Martin Hope
Sergio
Asked: 2024-05-17 23:29:55 +0800 CST
  • 6

我有一个由两个驱动器组成的镜像配置的 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：我已经在进行第二次备份，但我更愿意解决这个问题（用于练习），而不是建立一个新的池。

zfs
Martin Hope
mikem
Asked: 2023-12-06 15:02:39 +0800 CST
  • 6

我不小心将不匹配的 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

这看起来很奇怪，因为我实际上只是添加了它并且没有向池中写入任何内容。

我可以接受它，因为它似乎给了我我所期望的空间，但我只是想更好地理解我将与之共处的魔鬼。

zfs
Martin Hope
rptb1
Asked: 2023-10-10 01:15:42 +0800 CST
  • 10

我在 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
Martin Hope
Xavanteex
Asked: 2023-09-20 02:20:05 +0800 CST
  • 5

我已经在我的 ZFS 池上设置了定期清理，并开始考虑时不时地设置智能检查，但我对一个条目有清晰的记忆，我无法发现不应安排重叠时间。在安排时是否应该考虑任何此类考虑因素，例如清理、重新同步和智能检查？清理和重新同步似乎很明显，但是在其他磁盘维护操作之间呢？虽然我读到一些关于在多个池上不重叠清理的讨论，但在对 raid 阵列运行智能检查并在同一系统中的池上运行清理时是否应该考虑这一点？

zfs
Martin Hope
Jonathan
Asked: 2023-09-16 00:14:42 +0800 CST
  • 5

只是一个简单的理解问题。我有一台 TrueNas Scale 服务器，我刚刚将加密方法从密钥更改为密码。现在我想知道是否需要重写整个数据集才能应用此功能？我的数据现在在磁盘上是未加密的还是使用旧密钥的？感谢您的帮助 ：）

zfs
Martin Hope
Frank Vermeulen
Asked: 2023-08-27 04:53:02 +0800 CST
  • 13

我正在尝试对全 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

关于我的带宽去了哪里有什么见解吗？

zfs
Martin Hope
Joachim Sauer
Asked: 2023-08-22 01:21:11 +0800 CST
  • 7

首先：我完全可以接受目前的情况，并且不是在寻找立即的解决方案，而是试图了解此约束的技术限制。

我主要在 Linux 上使用 ZFS，但我的理解是，所有 FOSS ZFS 开发现在都植根于 OpenZFS，因此任何/所有其变体的信息都值得赞赏。

手册页指出zfs remove：

仅当主池存储不包含顶级 raidz vdev、所有顶级 vdev 具有相同扇区大小并且加载所有加密数据集的密钥时，才能删除顶级 vdev。

我理解和/或可以猜测大多数这些限制的原因，但我并不真正理解为什么仅仅存在raidz vdev 就会阻止删除任何（甚至是镜像或非冗余）vdev。

我的理解/假设是，从池的角度来看，每个 vdev 充当“哑块设备”，实际的冗余/镜像发生在 vdev 级别（正如池级别没有冗余的重复警告所暗示的那样：所有vdev 级别必须存在冗余，单个 vdev 发生故障会导致整个池停机）。

在这种假设下，删除什么特定数据 vdev 并不重要，更不用说池中存在“坏”(raidz) vdev 。

显然，这种假设（或我想不到的其他假设）是错误的。有人可以启发我什么吗？

我唯一无法验证的猜测是，raidz vdevs 没有绝对原因阻止 vdev 删除，但是某些 raidz 特定操作和设备删除之间的某些交互根本没有实现/测试/至此已验证。

zfs