ZFS 文件系統上的可用空間意外失去

將完全改寫這個問題，因為幾個月後它仍然是一個懸而未決的生產問題。

我有一個 FreeNAS 0.7.2 機器，基於 FreeBSD 7.3-RELEASE-p1，在 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
• 使用 /dev/zero 作為輸入使用 dd 創建文件，使用 rm 刪除文件，全部作為 root
• 文件肯定被刪除了
• Windows 可以通過 SMB 查看文件夾
• Windows 版本為 7
• 不確定如何確定以下回答者建議的錯誤是否已在 ZFS 池和我正在使用的 FreeBSD 中的 FS 版本中得到解決

問你喜歡的任何問題，我可以從任何地方得到盒子上的外殼。

非常感謝任何建議或想法。湯姆

解決方案最終來自 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

認為值得將其發佈在這裡並將其標記為答案，即使在此之後也是如此。

引用自：https://serverfault.com/questions/192927