☰

zfs linux 文件级磁盘使用混乱

tag-icon • tag-icon zfs
zfs linux 文件级磁盘使用混乱

我在 Linux 上使用 ZFS，我很困惑为什么文件的实际磁盘使用情况（由“du”报告）似乎到处都是。

我在硬件 Dell PERC RAID（仅 /dev/sdb）上创建了一个名为“vault”的池，采用除自动扩展“on”之外的所有默认值

然后我使用它创建了一个卷

-o 保留=2040G -o 配额=2040G -o 调整大小=4k -o acltype=posixacl

然后我将一个 ext4 卷同步到它。例如，此卷上有两个数据文件（Matlab *.mat 文件），大小分别为 13104 和 11264 字节。在 ext4 文件系统上，这些文件上的 du 分别表示 16K 和 12K，对应于 4K 块大小。任何 <4K 文件都将始终显示来自 du 的 4K。

相比之下，在 ZFS 上，这两个文件上的 du 分别显示 25K 和 21K，而在一个 1 字节文件上，我得到 4.5K。我猜由于各种元数据的使用，后者额外的 0.5K 并不太令人担忧。我运行过一些其他 <4K 文件，但返回的结果正好是 4K。最令人困惑的是为什么 *.mat 文件上的 du 几乎是“真实”数据大小的两倍？

答案1

您可以用来zdb确定这样的信息 - 只需获取索引节点和数据集。例如，如果您的数据集名为tank/foo，您可以使用ls -i来确定 inode 编号，然后zdb -ddddd tank/foo $INODE转储信息。

这是我机器上的一个例子：

# cd /var/tmp
# mkfile 13104 file1
# ls -i file1
  4125 file1
# zdb -ddddd rpool/VARSHARE/tmp 4125
Dataset rpool/VARSHARE/tmp [ZPL], ID 4128, cr_txg 928175, 8.24G, 1223 objects, rootbp DVA[0]=<0:1f62907a00:200:STD:1> DVA[1]=<0:f4a2eda00:200:STD:1> [L0 DMU objset] fletcher4 lzjb LE unique unencrypted size=800L/200P birth=14962025L/14962025P fill=1223 contiguous 2-copy cksum=1b152e5f60:7b661ed2ecb:1445f97091785:278e0e37baf85b

    Object  lvl   iblk   dblk  dsize  lsize   %full  type
      4125    1    16K  13.0K  13.0K  13.0K  100.00  ZFS plain file
                                        168   bonus  System attributes
        dnode flags: USED_BYTES USERUSED_ACCOUNTED 
        dnode maxblkid: 0
        path    /file1
        uid     0
        gid     0
        atime   Fri Sep  7 18:48:00 2018
        mtime   Fri Sep  7 18:48:00 2018
        ctime   Fri Sep  7 18:48:00 2018
        crtime  Fri Sep  7 18:48:00 2018
        gen     14962023
        mode    0100600
        size    13104
        parent  4
        links   1
        pflags  0x40800000204
Indirect blocks:
                 0 L0 0:0x1f55eb0200:0x3400 0x3400L/0x3400P F=1 B=14962023/14962023 ---

                segment [000000000000000000, 0x0000000000003400) size 13.0K
#

这将使您了解数据的大小以及文件正在消耗的元数据（标记为“间接块”）的数量。

在本例中，它准确分配了 13k 的块，并使用单个 16k 的间接块。因此，它使用 29k 来存储 13k 文件。我猜你们的数字会相似。

请注意，16k“iblk”很可能已被压缩，因此可以肯定它在物理上仅占用 4k。

相关内容