zfs destroy on a zvol snapshot doesn't remove /dev/zd* device #903
Comments
|
Thanks for doing the leg work, we'll get that fixed for -rc11 |
|
Didn't mean to close this issue. I thought ""Close" meant close the window. |
The 'zfs destroy' changes in 330d06f disrupted how zvol devices get removed on ZoL. However, it basically boils down to the fact that we are no longer reliably calling zvol_remove_minor() via zfs_ioc_destroy_snaps(). Therefore we add the missing call and handle things similarly to the existing zfs_unmount_snap() case. Ideally we would check if this is of type DMU_OST_ZFS or DMU_OST_ZVOL and just do the right thing as in zfs_ioc_destroy(). However, it looks like it would be fairly expensive to get the type, and it's harmless to simply attempt the umount and minor removal. It's not exactly clear to me why this wasn't an issue for the upstream Illumos code. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue openzfs#903
|
I confirmed pull request #946 applied to zfs-0.6.0-rc10 fixes the issue. The /dev/zd* nodes are removed on zvol snapshot destroy. |
|
I can confirm this issue on FreeBSD and on OpenIndiana (illumos). Illumos issue filed: |
|
@mmatuska I'm of the opinion that the attribution in the git/svn/hg commit is enough, but if you need to add it then it's best to go with me in person. Portions Copyright 2012 Brian Behlendorf behlendorf1@llnl.gov And thanks for checking this out for me on FreeBSD and OpenIndiana, and for opening the Illumos issue. I was fairly sure they were going to have the same issue since I couldn't identify any other machinery which would do the job. |
The 'zfs destroy' changes in 330d06f disrupted how zvol devices get removed on ZoL. However, it basically boils down to the fact that we are no longer reliably calling zvol_remove_minor() via zfs_ioc_destroy_snaps(). Therefore we add the missing call and handle things similarly to the existing zfs_unmount_snap() case. Ideally we would check if this is of type DMU_OST_ZFS or DMU_OST_ZVOL and just do the right thing as in zfs_ioc_destroy(). However, it looks like it would be fairly expensive to get the type, and it's harmless to simply attempt the umount and minor removal. This is also an issue in the latest FreeBSD and Illumos code. It was being tracked under the following issue, and we may want to refresh our code when they settle on what they want to do about it upstream. https://www.illumos.org/issues/3170 Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue #903
|
I am looking into porting |
|
@ryao If you can bring us more in sync with Illumos while porting 3744 I'm all for it. |
|
Subsequent testing revealed that the current location is fine. #1775 retained the current location. |
|
I'm seeing something that looks like a regression of this issue with 0.6.3-2~trusty. I have a system that has in the order of 100 snapshots, but over 24000 /dev/zd* devices. This machine does a lot of snapshot creation/deletion on zvols. Incidentally, I noticed this while investigating poor IO performance on this system. I wonder if the clutter of zvol devices could be the reason for the poor performance I'm seeing. Update: it looks like this happens only if the property snapdev is set to "visible" on the pool. I have other machines that perform similar work, but they don't have a proliferation of zd devices. Only the one with the problem had snapdev=visible (I've turned it off now and I'll report whether that stopped the proliferation). |
Creating a snapshot on a zvol followed by a destroy does not remove the /dev/zd* device file. Over time, the /dev directory fills up with invalid device nodes.
I've confirmed the problem appears within the zfs commit : 330d06f Illumos #1644, #1645, #1646, #1647, #1708 . Reverting this commit from a checked out zfs-0.6.0-rc10 tag fixes the issue.
Steps to reproduce:
The /dev/zd* node is removed if the pool is destroyed.
The text was updated successfully, but these errors were encountered: