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: [email protected]
Reporter: [email protected]
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.
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "[email protected]"
