Date: Sun, 19 Jul 2020 13:44:44 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 248105] Some zfs snapshots are busy within the ZCP domain but can still be destroyed from userland Message-ID: <bug-248105-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248105 Bug ID: 248105 Summary: Some zfs snapshots are busy within the ZCP domain but can still be destroyed from userland Product: Base System Version: 12.1-STABLE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: bsdpr@phoe.frmug.org On a host running 12-STABLE (rev 360207) I observe an inconsistent behavior from zfs when attempting to destroy snapshots. From a zfs channel program, a call to zfs.sync.destroy() fails and return EBUSY. That is extremely strange as the affected snapshot is not a clone source and can be destroyed without error with the 'zfs destroy' command. I observed that the ZCP I'm using stopped functioning correctly due to this bug after I accessed the contents of another (more recent) snapshot via the .zfs/snapshot facility. Snapshots created after accessing .zfs/snapshot are not deemed busy while all snapshots created before the access are busy from the ZCP domain. By accessing .zfs/snapshot I mean listing the contents of .zfs/snapshot, listing the contents of a given snapshot, and eventually copying a file from that same snapshot. As a summary, please consider the following layout: pool/fs@snapA pool/fs@snapB pool/fs@snapC pool/fs@snapD on which the following actions are applied (with their outcome): zfs.sync.destroy("pool/fs@snapA") -- will succeed $ ls pool/fs/.zfs/snapC $ ls pool/fs/.zfs/snapC/ $ cp pool/fs/.zfs/snapC/file /tmp/discard zfs.sync.destroy("pool/fs@snapB") -- will fail $ zfs destroy pool/fs@snapB # will succeed $ zfs snapshot pool/fs@snapE zfs.sync.destroy("pool/fs@snapE") -- will succeed zfs.sync.destroy("pool/fs@snapD") -- will fail $ zfs destroy pool/fs@snapD # will succeed -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-248105-227>