• Home
  • Categories
  • WIKI
  • LANGUAGE: en
    • [Feedback on issues] 文件管理器对btrfs子卷的兼容性问题
    deepin 25 128 views · 2 replies ·
    Tofloor
    poster avatar
    asjayli
    deepin
    2026-01-22 14:38
    Author

    文件管理器未能正确识别btrfs分区共享的数据块，导致磁盘占用统计不准确。

    因为本地配置了各分区自动创建btrfs子卷当快照的备份策略，发现文件管理器显示磁盘爆满，btrfs显示正常，清理了部分备份快照后显示才降下来，下面的数据是只有一个备份快照的情况，而且还没有做什么操作，就算有CoW差异，也肯定很小

    image.png
    Reply Favorite View the author
    All Replies
    LiuYongzhang
    deepin
    2026-01-22 15:21
    #1

    据说在btrfs文件格式下新建的文件搜索不到，必须重新启动电脑才能搜索到新文件

    Reply View the author
    夜夜笙歌free
    deepin
    2026-01-22 15:59
    #2

    AI分析了下你的数据：

    这是一个非常合理的现象。简单来说，产生差异的原因在于 Btrfs 的文件系统特性 以及 文件管理器/磁盘分析工具的计算方式 不同。

    结论先行

    文件管理器显示 246.4G 是合理的，它是基于 statfs 系统调用计算的“已用”空间。

    这个数字（246.4G）大致等于你的 实际数据量 (150.21G) + 元数据占用总量 (96.00G)。

    详细分析

    我们可以通过你提供的 btrfs filesystem usage 数据来拆解这 246.4G 是怎么来的：

    1. 数据层面的占用 (Data, single)

    • 输出信息： Data,single: Size:510.00GiB, Used:150.21GiB
    • 解释：
      • 实际存储的用户文件（你的照片、文档等）大约占用 150.21 GiB。
      • Btrfs 预留了 510 GiB 的空间给数据使用，但这其中有很多是空的（预留但未写入）。
      • 因为数据的 RAID 级别是 single（无冗余），这些预留的空闲空间（约 360GiB）操作系统认为可以随时存入文件，所以在计算“已用”和“可用”时，这部分并没有被算作“已用”，而是算作了“可用”（即 Free (statfs) 的一部分）。
  • 输出信息： 96.00GiB
  • 解释（这是关键）：
    • 你的文件系统为了安全，对元数据（即记录文件名、目录结构、数据位置等信息的数据）使用了 DUP（Duplicate）模式。这意味着元数据在磁盘上存了两份。
    • 逻辑大小是 48 GiB，因为存了两份，所以实际物理占用是 96.00 GiB。
    • 虽然目前只用了 4.31 GiB（逻辑），但 Btrfs 已经锁定了 96 GiB 的物理空间专门给元数据使用。
    • 这块空间是专用的，普通用户数据不能往里写。因此，操作系统（df 命令或文件管理器）通常会把所有被元数据分配占用的物理空间 (96 GiB) 都算作“已用空间”。

    • 3. 算术验证

    文件管理器的计算逻辑通常是： 总容量−可用空间(𝑠𝑡𝑎𝑡𝑓𝑠)=显示已用总容量−可用空间(statfs**)**=**显示已用**

    让我们代入你的数据：

    • 总容量： 883.84 GiB
    • 可用空间 来自输出： 637.56 GiB (这包含了未分配的 277.77G + 数据区剩余的空闲空间)
    • 计算显示已用： 883.84−637.56=246.28 GiB883.84−637.56=**246.28** GiB

    这与文件管理器显示的 246.4G 完美吻合。

    再看看这 246.28G 的组成： 150.21 (实际数据)+96.00 (元数据物理占用)+少量系统占用≈246.2 GiB150.21 (实际数据)+96.00 (元数据物理占用)+少量系统占用≈246.2 GiB

    Reply View the author