☰

ZFS Inode 消耗

tag-icon • tag-icon debian zfs inode
ZFS Inode 消耗

我在 raid Z1 中有一个大约 90TB 左右的 ZFS 池，充当 PLEX 服务器。我目前有大约 300GB 的可用空间。平均而言，大多数文件每个大小为 70-80GB。

如果我复制较小的文件（约 10GB），就没有问题。传输成功，不影响INode消费。

如果我复制大文件（约 70GB），Inode 消耗会从 1% 跃升至 100%，这在单个文件的范围内是不可能的。如果我删除该文件，消耗量会回落到 1%。这不仅仅是一个大文件，任何大文件都会导致同样的问题。

我已经使用 wget （远程 FTP）复制文件或直接作为 NFS 挂载复制文件，消耗行为是相同的。

下列的本指南，似乎由于默认记录大小为 128KB，索引节点由于消耗它们的文件大小而很快被消耗。

它是否正确？ 1MB 记录大小可以解决这个问题吗？

池状态

root@pve:~# zpool status pool
  pool: pool
 state: ONLINE
  scan: scrub in progress since Thu Jul 27 18:40:26 2023
        25.0T scanned at 478M/s, 23.6T issued at 450M/s, 76.1T total
        0B repaired, 30.99% done, 1 days 10:00:10 to go
config:

        NAME                                 STATE     READ WRITE CKSUM
        pool                                 ONLINE       0     0     0
          raidz1-0                           ONLINE       0     0     0
            ata-ST6000VN001-2BB186_XXXXXXXX  ONLINE       0     0     0
            ata-ST6000VN001-2BB186_XXXXXXXX  ONLINE       0     0     0
            ata-ST6000VN001-2BB186_XXXXXXXX  ONLINE       0     0     0
          raidz1-1                           ONLINE       0     0     0
            ata-ST6000VN001-2BB186_XXXXXXXX  ONLINE       0     0     0
            ata-ST6000VN001-2BB186_XXXXXXXX  ONLINE       0     0     0
            ata-ST6000VN001-2BB186_XXXXXXXX  ONLINE       0     0     0
          raidz1-2                           ONLINE       0     0     0
            ata-ST8000VN004-2M2101_XXXXXXXX  ONLINE       0     0     0
            ata-ST8000VN004-2M2101_XXXXXXXX  ONLINE       0     0     0
            ata-ST8000VN004-2M2101_XXXXXXXX  ONLINE       0     0     0
          raidz1-3                           ONLINE       0     0     0
            ata-ST8000VN004-2M2101_XXXXXXXX  ONLINE       0     0     0
            ata-ST8000VN004-2M2101_XXXXXXXX  ONLINE       0     0     0
            ata-ST8000VN004-2M2101_XXXXXXXX  ONLINE       0     0     0

errors: No known data errors

root@pve:~# zfs get all pool
NAME  PROPERTY              VALUE                  SOURCE
pool  recordsize            128K                   default

Inode 消耗（文件前复制）

共享目录是保存 PLEX 文件的位置。

root@pve:\~# df -ih
Filesystem           Inodes IUsed IFree IUse% Mounted on
pool                    87M    17   87M    1% /pool
pool/share              87M   36K   87M    1% /pool/share
pool/main               87M    12   87M    1% /pool/main

Inode 消耗（文件复制后）

root@pve:~# df -ih
Filesystem           Inodes IUsed IFree IUse% Mounted on
pool                     17    17     0  100% /pool
pool/share              36K   36K     0  100% /pool/share
pool/main                12    12     0  100% /pool/main

答案1

系统调用报告的索引节点使用情况statvfs()（df幕后使用的内容）对于 ZFS 来说并不是很有用。

传统上，文件系统具有固定数量的 inode，因此很容易报告总数和空闲数。 ZFS 根据需要分配更多 inode（实际上是“dnode”，一个类似的 ZFS 特定概念）。

它报告的“空闲”数字statvfs()是 ZFS 可以从池上的剩余空间（或数据集配额，如果设置了）中分配的 dnode 数量。然后总计为免费+已使用。 （来源）

因此，要了解此处“空闲索引节点”的情况，您可能需要查看池上的总体空间使用情况。您的副本是否填满了剩余空间？

一般来说，zpool list它zfs list会让您更好地了解您的空间的去向。这并不总是那么容易； ZFS 空间预测往往不准确，因为它有许多使用和不使用空间的策略，具体取决于池的构建方式、池和数据集的配置方式以及实际有多少可用空间。

最后，记录大小不会对使用的 dnode 数量产生影响，但较大的块大小可能意味着压缩效果不佳的数据（例如视频）（或者如果压缩关闭）会浪费更多空间，如上所述，这改变了对“空闲索引节点”的猜测的计算。

但最重要的是：如果除了 中明显的 inode 使用情况之外，一切看起来都很好df，那么就不用担心它 - 实际上，它毫无意义。

相关内容