要彻底改写这个问题，因为几个月后它仍然是一个突出的生产问题。
我有一个基于FreeBSD 7.3-RELEASE-p1的FreeNAS 0.7.2盒子，在RAIDz1中运行带有4x1TB SATA驱动器的ZFS。
在创build和删除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 问任何你喜欢的问题，我可以从任何地方壳上壳。
真的很感激任何意见或想法。 汤姆
解决scheme最终通过zfs-discuss邮件列表来发送 – 这篇文章 。
看起来zfs list -t snapshot的输出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
我认为这是值得在这里发表，并标记为答案，即使在这个时候。
listsnapshots是一个属性，它仅控制zfs list的默认输出是否显示快照。 它不会“启用或禁用快照”。
要列出包括快照的所有内容，请使用以下命令：
zfs list -t all
要仅列出快照，请使用以下命令：
zfs list -t snapshot
编辑 ：你可能遇到了这个ZFS的错误 。 要确认这个错误是什么原因，请使用非稀疏文件重试。 该错误应该只发生在大型稀疏文件上，比如mkfile或者从/dev/zero复制。
这个错误在Solaris中已经修复，但是可能仍然存在于你正在使用的FreeBSD版本中。
在我的机器上，通常需要15秒才能更新磁盘使用统计信息。 也许你只是没有耐心。