ZFS rename with associated snapshot present: odd error message

Discussion:

Mark Millard via freebsd-current

2021-05-04 22:59:13 UTC

I had a:

# zfs list -tall
NAME USED AVAIL REFER MOUNTPOINT
. . .
zroot/DESTDIRs/13_0R-CA72-instwrld-norm 1.44G 117G 96K /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm
zroot/DESTDIRs/13_0R-CA72-instwrld-***@dirty-style 1.44G - 1.44G -. . .
. . .

(copied/pasted from somewhat earlier) and then attempted:

# zfs rename zroot/DESTDIRs/13_0R-CA72-instwrld-norm zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0
cannot open 'zroot/DESTDIRs/13_0R-CA72-instwrld-***@dirty-style': snapshot delimiter '@' is not expected here

Despite the "cannot open" message, the result looks like:

# zfs list -tall
NAME USED AVAIL REFER MOUNTPOINT
. . .
zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0 1.44G 114G 96K /usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt-0
zroot/DESTDIRs/13_0R-CA72-instwrld-alt-***@dirty-style 1.44G - 1.44G -
. . .

Still, it leaves me wondering if everything is okay
given that internal attempt to use the old name with
@dirty-style when it was apparently no longer
available under that naming.

For reference:

# uname -apKU
FreeBSD CA72_4c8G_ZFS 13.0-RELEASE FreeBSD 13.0-RELEASE #0 releng/13.0-n244733-ea31abc261ff-dirty: Thu Apr 29 21:53:20 PDT 2021 ***@CA72_4c8G_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1300139 1300139

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

Andriy Gapon

2021-05-05 09:47:35 UTC

Permalink

Post by Mark Millard via freebsd-current
# zfs list -tall
NAME USED AVAIL REFER MOUNTPOINT
. . .
zroot/DESTDIRs/13_0R-CA72-instwrld-norm 1.44G 117G 96K /usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm
. . .
# zfs rename zroot/DESTDIRs/13_0R-CA72-instwrld-norm zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0
# zfs list -tall
NAME USED AVAIL REFER MOUNTPOINT
. . .
zroot/DESTDIRs/13_0R-CA72-instwrld-alt-0 1.44G 114G 96K /usr/obj/DESTDIRs/13_0R-CA72-instwrld-alt-0
. . .
Still, it leaves me wondering if everything is okay
given that internal attempt to use the old name with
@dirty-style when it was apparently no longer
available under that naming.
# uname -apKU

Cannot reproduce here (but with much simpler names and on stable/13):
zfs create testz/test
zfs snapshot testz/***@snap1
zfs rename testz/test testz/test2

All worked.

--
Andriy Gapon

Mark Millard via freebsd-current

2021-05-05 12:28:27 UTC

Permalink

Post by Andriy Gapon

zfs create testz/test
zfs rename testz/test testz/test2
All worked.

I've noticed that sometimes in my explorations it has been
silent instead of complaining. I've no clue at this point
what prior activity (or lack of activity) makes the
difference for if a message will be generated vs. not.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

Mark Millard via freebsd-current

2021-05-05 22:53:41 UTC

Permalink

Post by Mark Millard via freebsd-current

Post by Andriy Gapon

zfs create testz/test
zfs rename testz/test testz/test2
All worked.

One difference in context is that your above sort of sequence
generates the after-snapshot context (using some things I have
around now):

zroot/DESTDIRs/13_0R-CA53-poud 1.45G 127G 1.45G /usr/obj/DESTDIRs/13_0R-CA53-poud
zroot/DESTDIRs/13_0R-CA53-***@test 0B - 1.45G -

where my example had something more like (hand edited
the above just for illustration):

zroot/DESTDIRs/13_0R-CA53-poud 1.45G 125G 96K /usr/obj/DESTDIRs/13_0R-CA53-poud
zroot/DESTDIRs/13_0R-CA53-***@test 1.45G - 1.45G -

before the rename. In other words, I'd updated the
original (almost?) completely after the snapshot
(as a side effect of my overall activity). It was
only later that I tried the rename to track a new
purpose/context that I was going to switch to.

I'm not claiming that such is sufficient to
(always? ever?) reproduce the message. I'm
just pointing out that I'd had some significant
activity on the writable file system before the
rename.

Some of my activity has been more like your test
and I'd not seen the problems from such. But it
is not a very good comparison/contrast context
so I'd not infer much. I still can not at-will
set up a context to produce the messages.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)