[Bug 248105] Some zfs snapshots are busy within the ZCP domain but can still be destroyed from userland

[bugzilla-noreply at freebsd.org]

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 at FreeBSD.org
          Reporter: bsdpr at 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 at snapA
pool/fs at snapB
pool/fs at snapC
pool/fs at snapD

on which the following actions are applied (with their outcome):

zfs.sync.destroy("pool/fs at 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 at snapB")  -- will fail
$ zfs destroy pool/fs at snapB        #  will succeed
$ zfs snapshot pool/fs at snapE
zfs.sync.destroy("pool/fs at snapE")  -- will succeed
zfs.sync.destroy("pool/fs at snapD")  -- will fail
$ zfs destroy pool/fs at snapD        #  will succeed

-- 
You are receiving this mail because:
You are the assignee for the bug.