☰

zfs-单磁盘设置：缺少的空间在哪里？

tag-icon • tag-icon 20.04 disk-usage zfs
zfs-单磁盘设置：缺少的空间在哪里？

简短的摘要：

创建仅由一个容量为 1TB（= 931GiB）的磁盘组成的单个 zfs 磁盘池时，文件系统仅显示 899 GiB 的可用空间（df -h或zfs list；zpool list实际上显示分区大小（931 GiB）减去一些开销（导致 928 GiB 空间）。

较长的版本：

我试图设置一个仅由一个容量为 1TB（= 931,53 GiB）的磁盘组成的 zfs 磁盘池：

# fdisk -l /dev/sdb
Disk /dev/sdb: 931.53 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: xxxx
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: xxx

Device     Start        End    Sectors   Size Type
/dev/sdb1   2048 1953516976 1953514929 931.5G Linux filesystem

设置 zfs 池时

# zpool create -f -o ashift=12 tank /dev/sdb1;

缺少 32,5 GiB：

# zfs list
NAME   USED  AVAIL     REFER  MOUNTPOINT
tank   360K   899G       96K  /tank

什么原因导致单个磁盘设置产生 32.5 GiB 的开销？

zpool list正在报告：

# zpool list
NAME   SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
tank   928G   444K   928G        -         -     0%     0%  1.00x    ONLINE  -

但这不是实际可用的空间，因为还df -h报告：

# df -h
Filesystem                  Size  Used Avail Use% Mounted on
tank                        899G  128K  899G   1% /tank

没有设置配额或预留：

# zfs get quota
NAME  PROPERTY  VALUE  SOURCE
tank  quota     none   default

# zfs get reservation
NAME  PROPERTY     VALUE   SOURCE
tank  reservation  none    default

# zfs get refquota
NAME  PROPERTY  VALUE   SOURCE
tank  refquota  none    default

# zfs get refreservation
NAME  PROPERTY        VALUE      SOURCE
tank  refreservation  none       default

# zfs get usedbyrefreservation
NAME  PROPERTY              VALUE          SOURCE
tank  usedbyrefreservation  0B             -

创建 zpoolashift=9没有任何区别。

我可以忍受 3.5 GiB 的实际开销（= 分区大小 vs. zpool 报告的大小），但不能忍受这么小的磁盘上的 32.5 GiB 或 29 GiB 的开销（= zfs 报告的大小 - zpool 报告的大小）。

当尝试使用 btrfs 进行相同操作时，我获得了更多的可用空间：

# btrfs filesystem show
Label: 'tank'  uuid: xxx
        Total devices 1 FS bytes used 128.00KiB
        devid    1 size 931.51GiB used 2.02GiB path /dev/sdb1

# df -h
Filesystem                  Size  Used Avail Use% Mounted on
/dev/sdb1                   932G  3.8M  930G   1% /mnt

更多细节

# zfs --version
zfs-0.8.3-1ubuntu12.5
zfs-kmod-0.8.3-1ubuntu12.5

# uname -a
Linux xxx 5.4.0-58-generic #64-Ubuntu SMP Wed Dec 9 08:16:25 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

# cat /etc/os-release | grep VERSION
VERSION="20.04.1 LTS (Focal Fossa)"
VERSION_ID="20.04"
VERSION_CODENAME=focal

# zfs list -o space
NAME  AVAIL   USED  USEDSNAP  USEDDS  USEDREFRESERV  USEDCHILD
tank   899G  88.5K        0B     24K             0B      64.5K

更新：使用命令重新创建zpool create -oashift=12 tank /dev/sdb1。

没有不同：

# zpool list
NAME             SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
tank             928G   432K   928G        -         -     0%     0%  1.00x    ONLINE  -

# zfs list
NAME                  USED  AVAIL     REFER  MOUNTPOINT
tank                  336K   899G       96K  /tank

输出zdb tank | grep metaslab | tail -n 3：

# zdb tank | grep metaslab | tail -n 3
loading concrete vdev 0, metaslab 115 of 116 ...
        metaslab    114   offset   e400000000   spacemap      0   free       8G
        metaslab    115   offset   e600000000   spacemap      0   free       8G
        vdev          0         metaslabs  116          fragmentation  0%

输出zdb | grep metaslab_shift：

# zdb | grep metaslab_shift
            metaslab_shift: 33

答案1

我无法重现您的问题。

root@banshee:/tmp# truncate -s 931G disk.bin
root@banshee:/tmp# zpool create -oashift=12 test /tmp/disk.bin
root@banshee:/tmp# zpool list test
NAME   SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
test   928G   480K   928G        -         -     0%     0%  1.00x    ONLINE  -

在上面的例子中，我从一个 931GiB（大约 1TB）的块设备开始，并使用 4KiB 扇区在其上创建一个池。可用容量为 928GiB，这与您在考虑 metaslab 余数时预期的一样。

root@banshee:/tmp# zdb test | grep metaslab | tail -n 3
loading concrete vdev 0, metaslab 115 of 116 ...
    metaslab    114   offset   e400000000   spacemap      0   free       8G
    metaslab    115   offset   e600000000   spacemap      0   free       8G
    vdev          0     metaslabs  116      fragmentation  0%

我的 931GiB“磁盘”被分成 116 个 8GiB 元板；这留下了 0.44125 元板余数。

0.44125 metaslabs * 8GiB/metaslab == 3.53GiB

931GiB disk - 3.53Gib metaslab remainder == ~~928GiB usable

... 真是了不起。为什么您会看到大约十倍的开销，我不知道；我也在用 Focal，ZFS 版本和您报告的一样。

root@banshee:/tmp# apt policy zfsutils-linux
zfsutils-linux:
  Installed: 0.8.3-1ubuntu12.5
  Candidate: 0.8.3-1ubuntu12.5
  Version table:
 *** 0.8.3-1ubuntu12.5 500
        500 http://us.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     0.8.3-1ubuntu12 500
        500 http://us.archive.ubuntu.com/ubuntu focal/main amd64 Packages

zdb | grep metaslab_shift从头开始逐个命令地查看池本身的实际创建过程和/或该池的输出可能会有所帮助。

答案2

正如 subreddit /r/zfs 中的用户 grenkins 所指出的那样（https://www.reddit.com/r/zfs/comments/kp2nnk/zfs_single_disk_setup_1tb_9315_gib_325_gib/- 所有功劳都归于他）zfs 默认预留 3.2% 的空间。此预留由系统上的内核模块完成，与配额/预留/refquota/refreservation/usedbyrefreservation zpool 设置无关。请参阅https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Module%20Parameters.html#spa-slop-shift

保留由 zfs 内核模块的 spa_slop_shift 设置完成。

概括：

Normally, the last 3.2% (1/(2^spa_slop_shift)) of pool space is reserved to ensure the pool doesn’t run completely out of space [...]
For large pools, when 3.2% may be too conservative and more usable space is desired, consider increasing spa_slop_shift

我通过创建以下文件将 spa_slop_shift 设置增加到 15：

# printf "options zfs spa_slop_shift=15" > /etc/modprobe.d/zfs.conf

重启后有 928 GiB 可用：

# zpool list
NAME   SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
tank   928G   576K   928G        -         -     0%     0%  1.00x    ONLINE  -

# zfs list
NAME   USED  AVAIL     REFER  MOUNTPOINT
tank   408K   928G       96K  /tank

这实际上是报告的可用空间zpool list（931,5 分区大小 - 一些小的开销）。

所以这对我来说已经解决了。

相关内容