Bug 226499 - Partial system freeze via ZFS rename and possible other operations
Summary: Partial system freeze via ZFS rename and possible other operations
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 11.1-RELEASE
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-fs (Nobody)
: 227740 (view as bug list)
Depends on:
Reported: 2018-03-10 14:27 UTC by Paul Webster
Modified: 2020-09-15 09:06 UTC (History)
3 users (show)

See Also:

Log file of various states to reproduce (70.90 KB, text/plain)
2018-03-17 16:34 UTC, Paul Webster
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Webster 2018-03-10 14:27:48 UTC
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.
Comment 1 Paul Webster 2018-03-10 14:34:38 UTC
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.
Comment 2 Paul Webster 2018-03-10 14:38:53 UTC
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.
Comment 3 Andriy Gapon freebsd_committer 2018-03-11 09:12:56 UTC
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.
Comment 4 Paul Webster 2018-03-11 17:38:13 UTC
(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
Comment 5 Paul Webster 2018-03-17 16:34:29 UTC
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?
Comment 6 Paul Webster 2018-03-17 16:35:27 UTC
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 :)
Comment 7 mlavkin 2018-11-28 06:46:04 UTC
I have same issue on 11.0R and 11.2R-p4 :(
Comment 8 mlavkin 2018-11-28 06:49:33 UTC
But in my case it's snapshot rename.
Comment 9 emz 2018-12-07 05:31:24 UTC
*** Bug 227740 has been marked as a duplicate of this bug. ***
Comment 10 Andriy Gapon freebsd_committer 2020-09-15 09:06:55 UTC
Is this still a problem in 12.1 or 11.4 ?