Hi, I was suffering for weeks from the following problem: a zfs dataset contained an automatic snapshot (monthly) that used 2.8 TB of data. The dataset was deprecated, so I chose to destroy it after I had deleted some files; eventually it was completely blank besides the snapshot that still locked 2.8 TB on the pool.
'zfs destroy -r pool/dataset' hung the machine within seconds to be completely unresponsive. No respective messages could be found in logs. The issue was reproducible. The same happened for 'zfs destroy pool/data...@snapshot' Thus, the conclusion was that the snapshot was indeed the problem. Solution: After trying several things, including updating the system to snv_130 and snv_131, I had the idea to restore the dataset to the snapshot before doing another zfs destroy attempt. 'zfs rollback pool/data...@snapshot' 'zfs unmount -f pool/dataset' 'zfs destroy -r pool/dataset' Et voilà! It worked. Conclusion: I guess there is something wrong in zfs handling snapshots during a recursive dataset destruction. As it seems, the destruction is only successful if the dataset is consistent with the snapshot. Even if the workaround seems to be viable a fix of the issue would be appreciated. Regards, Tonmaus -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
