傳說中的 Bug
FreeNAS 用了這麼多年，終於被我遇到威傑科技 Jackson Wang 兄所提 Replication 的坑。
也就是當複寫一旦失敗後就不會繼續，永遠停在那裡。
發生狀況
首先，系統發出一封通知信
Hello,
The replication failed for the local ZFS StorageX/vmimg while attempting to apply incremental send of snapshot auto-20170415.0316-2m -> auto-20170417.0316-2m to 172.16.1.XXX
接著，問題發生的徵兆如下
- Push 發送端會有 replication failed 的錯誤
- Pull 接收端則是在快照介面，最後有一個 recv 名稱開頭的快照，容量為 0，表示失敗
而在 /var/log/messags 中，則有這段的訊息
從此之後，這兩台之間的複寫工作就再也不會成功。
嘗試解法
試了幾個招數，想要強制刪除這個快照讓複寫恢復正常運作：
- 手動從介面刪除該故障快照，失敗（dataset is Busy）
- 指令 zfs destroy 刪除該快照，失敗（dataset is Busy）
- 指令 zfs release 釋放它，失敗（no such tag on this dataset）
當中也試著用 ps aux | grep zfs 找出是否接收端有 Process 咬住 Dataset，卻也沒有發現。
確認結果
上述確認都沒辦法處理，最後只好放大絕 reboot 這台 FreeNAS，重開機完成後，已確認可以正常從介面刪除。
接下來複寫工作恢復正常，FreeNAS 有把故障這幾天的快照一一推送到接收端，解決！
目前來看，除了花錢購買 VRP (Volume Replication Package) 模組這條路之外，只能採用美中不足的「重開機 + 手動刪除快照」方法，希望 FreeNAS 上能有更好的解法出現。
最新戰況
2017/4/22 更新：
又發生了。
測試發現，從我在 FreeNAS 裡用 Jail 安裝 Duplicati 做檔案備份至雲端的機制後，這個情況才開始有產生。
每當 Replication Failed 發生時，我先做 Snapshot 給 Duplicati 讀取的那一份也從快照清單上消失，我備份前的 Script 是：
zfs destroy 資料集路徑@名稱
zfs snapshot 資料集路徑@名稱目前初步懷疑這個「快照」的動作，是造成頻繁 Failed 的原因之一，已做修改，繼續觀察中。
2017/4/26 更新：
觀察了四天，只要有做上述的快照銷毀與產生就會發生。
拿掉以後，確認複寫都已正常沒有再出現過失敗，因此幾乎可證明是我上面寫的 Script 所造成。
也就是說，用來接收遠端推過來複寫的這個 Dataset，最好不要另外再自己做其它快照，不管是手動還是排程，都會因此影響複寫接收的成功率。
