![ZFS Inode 消耗](https://linux22.com/image/222955/ZFS%20Inode%20%E6%B6%88%E8%80%97.png)
我在 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
,那么就不用担心它 - 实际上,它毫无意义。