It is possible to create a partial system freeze with zfs by renaming an active mountpoint; in my case I had a vdev mounted within bhyve. When I accidentally did a: 665 19:39 zfs rename zroot/venv/store/paul.daemon.space-extended zroot/venv/store/services.daemon.space-extended The zfs command froze and refuse to return (even via kill -9) the bhyve vm will refuse to exit, and the system will not reboot; it will get stuck trying to unmount filesystems. Likewise if you open up another terminal and try any command via 'zfs' it will end up in the frozen state, (actual state reported in top is: tx->tx) This is a partial freeze because all other system operations will continue normally. It appears though have not investigated earlier, that rename does not check a dataset is bust like destroy does, so then gets stuck in some sort of lock waiting for it to become available in the meantime nothing else can do anything, including any process that is actually locking whatever you are trying to rename.
It appears though have not investigated earlier, that rename does not check a dataset is bust like destroy does -> It appears, though I have not investigated, that rename does not check a dataset is busy like destroy does.
After rebooting, zroot/venv/store/paul.daemon.space-extended was still there obviously because it failed to rename, adding weight to this being some kind of lock issue.
You didn't tell us much about the filesystems involved. Which existed, which didn't it. Which was mounted, which wasn't. In any case, please try to reproduce and then run procstat -kk <pid-of-zfs-rename-command> Capturing the whole output of procstat -kk -a would be even better.
(In reply to Andriy Gapon from comment #3) My apologies, standard ZFS filesystem (hosting gpart/UFS on the vdev), bhyve had zroot/venv/store/paul.daemon.space-extended mounted. I have some testing to do with bhyve and snd-hda next weekend so I will also get some more debug information for this problem also
Created attachment 191580 [details] Log file of various states to reproduce Ok I just tried to recreate the problem I had on my server, with no luck what so ever using FreeBSD live.bsd 11.1-RELEASE-p8 FreeBSD 11.1-RELEASE-p8 #0 r331095 Though it does do something just as bad in reality, when you do a rename on it, it DOES do it immediately causing a panic on the bhyve instance when the disk goes bye-bye Surely I should not be able to rename a mounted vdev?
Note by panic, that is not an actual panic I meant the FreeBSD guest acts like the disk went away, not an actual .. well yes :)
I have same issue on 11.0R and 11.2R-p4 :(
But in my case it's snapshot rename.
*** Bug 227740 has been marked as a duplicate of this bug. ***
Is this still a problem in 12.1 or 11.4 ?