[0.8.3] zfs list -tall <zpool> does not work properly

[cdluminate]

System information

Type	Version/Name
Distribution Name	Debian
Distribution Version	Sid (unstable)
Linux Kernel	Debian 5.4.19-1 (2020-02-13)
Architecture	amd64
ZFS Version	0.8.3-1
SPL Version	N/A

Describe the problem you're observing

zfs list -tall <zpool> does not show the snapshots.

~ ❯❯❯ sudo zfs list -tsnap luminz | head -n5
NAME                                            USED  AVAIL     REFER  MOUNTPOINT
luminz@zfs-auto-snap_weekly-2020-01-18-0743       1K      -       25K  -
luminz@zfs-auto-snap_monthly-2020-01-20-0442      1K      -       25K  -
luminz@zfs-auto-snap_weekly-2020-01-25-1202       1K      -       24K  -
luminz@zfs-auto-snap_weekly-2020-02-01-0217       1K      -       24K  -
~ ❯❯❯ sudo zfs list -tall luminz | head -n5
NAME     USED  AVAIL     REFER  MOUNTPOINT
luminz   336G  67.4G       24K  /luminz

Describe how to reproduce the problem

Replay the commands.

Include any warning/errors/backtraces from the system logs

[DeHackEd]

When naming a specific dataset recursive display is not enabled by default. Use zfs list -r

[ghost]

Except it did recurse for -tsnap?

[DeHackEd]

I understand now. There's code to specifically handle requests for only snapshots or bookmarks which actually also sets -d1 -r. It's a convenience function for when you request these leaf dataset types, but specify a dataset that is not a snapshot. It works because since snapshots and bookmarks are children of specific datasets and leaves, these options do provide the intended result.

But -t all has no such side-effects.

So while it's a bit unexpected, I understand why it's happening... but what SHOULD it do then?

[zenaan]

but what SHOULD it do then?

Just hit this confusion now, after not needing to admin zfs for many moons, and it confused me for the last couple hours trying to find what I was doing wrong. I ran this command:

zfs list -t filesystem

and it was recursive across all filesystems (but I wasn't thinking "recursive", just "output"). Then I ran:

zfs list -t snap,filesystem pool1

and kept scratching my head, tried reversing the snap and filesystem types, and hours of similar and other distractions (I'm a bit slow sorry), trying to figure out why snapshots had disappeared/ were not being shown. The most confusing part was that the following command worked as expected:

zfs list -t snap pool1

, showed all snaps for that pool (which looks and feels "right").

The normal expectation for-t filesystem listing firesystems, and then -t snap listing snapshots, is that -t snap,filesystem must list both.

Deviation from this "adding another type, adds those extra things to the output" principle, is quite disorientating.

[stale[bot]]

This issue has been automatically marked as "stale" because it has not had any activity for a while. It will be closed in 90 days if no further activity occurs. Thank you for your contributions.

[behlendorf]

Reopening and tagging accordingly.