ZFS 文件系统上的可用空间意外丢失

Question

将完全改写这个问题，因为几个月后它仍然是一个悬而未决的生产问题。

我有一个基于 FreeBSD 7.3-RELEASE-p1 的 FreeNAS 0.7.2 盒，在 RAIDz1 中运行带有 4x1TB SATA 驱动器的 ZFS。

创建和删除 1TB 稀疏文件后，我似乎丢失了 1TB 的可用空间。这发生在几个月前。

这张表列出了目前的情况。

command         actual             expected           ok/not ok

du -c           1.47TB used        1.47TB used        ok

zfs list        used 2.48TB        used 1.47TB        not ok
                avail 206GB        avail 1.2TB        not ok

zpool list      size 3.64TB        size 3.64TB        ok
                used 3.31TB        used 1.95TB        not ok
                avail 334GB        avail 1.69TB       not ok

Windows right   Disk size 2.67TB   Disk size 2.67TB   ok
  click disk,   Used 2.47TB        Used 1.47          not ok
  properties    free 206GB         free 1.2TB         not ok

Windows select  total file size    total file size
  all files,      1.48TB             1.48TB           ok
  right click, 
  properties

• 池中的任何地方都没有快照
• 压缩已关闭
• 重复数据删除已关闭
• ZFS 池版本为 13
• ZFS FS 版本是 3
• 使用“嵌入式”版本的 FreeNAS
• 文件是使用 dd 创建的，使用 /dev/zero 作为输入，使用 rm 删除，全部为 root
• 文件肯定被删除了
• Windows 可以通过 SMB 查看文件夹
• Windows 版本是 7
• 不确定如何确定以下回答者建议的错误是否已在我使用的 FreeBSD 中的 ZFS 池和 FS 版本中解决

问你喜欢的任何问题，我可以从任何地方拿到盒子上的外壳。

真的很感激任何建议或想法。汤姆

Answer 1

解决方案最终来自 zfs-discuss 邮件列表 -这篇文章。

似乎zfs list -t snapshot在某个时候改变了输出，并且有一个隐藏的快照消耗了额外的空间：

There was a change where snapshots are no longer shown by default.
This can be configured back to the old behaviour setting the zpool 
"listsnapshots" property to "on"

Otherwise, you need to use the "-t snapshot" list.

But, a much better method of tracking this down is to use: 
    zfs list -o space

That will show the accounting for all dataset objects.
 -- richard

认为值得将其发布在这里并将其标记为答案，即使在此之后也是如此。