zfs destroy's and zfs rollback's error messages do not list blocking snapshots sorted

[ChristophSchmidpeter]

System information

Type	Version/Name
Distribution Name	Arch Linux
Distribution Version	NA
Kernel Version	5.14.2 (zen)
Architecture	x64
OpenZFS Version	2.1.1

Describe the problem you're observing

When multiple snapshots prevent the destruction/rollback of the respective dataset/snapshot/volume via zfs destroy or zfs rollback, the respective error message does not list the blocking snapshots sorted according to their order of creation.

Describe how to reproduce the problem

The commands

zfs create MyPool/Test
zfs snap MyPool/Test@Snap1
zfs snap MyPool/Test@Snap2
zfs snap MyPool/Test@Snap3
zfs snap MyPool/Test@Snap4
zfs snap MyPool/Test@Snap5
zfs snap MyPool/Test@Snap6
zfs destroy MyPool/Test

result in the following error message:

cannot destroy 'ZfsRoot/Test': filesystem has children
use '-r' to destroy the following datasets:
MyPool/Test@Snap3
MyPool/Test@Snap4
MyPool/Test@Snap6
MyPool/Test@Snap1
MyPool/Test@Snap5
MyPool/Test@Snap2

Equivalent behaviour occurs when trying to roll back to a blocked snapshot, e.g. via zfs rollback MyPool/Test@Snap1

Notice how, as mentioned, the resulting error message does not list the snapshots 1-6 in the order of their creation. This results in the error message being somewhat confusing/less intuitive and less informative and thus less useful. It also results in a less uniform behaviour, as zfs list -t snap MyPool/Test in contrast sorts the blocking snapshots in the order of their creation already:

zfs list -t snap MyPool/Test

NAME                 USED  AVAIL     REFER  MOUNTPOINT
MyPool/Test@Snap1     0B      -      304K  -
MyPool/Test@Snap2     0B      -      304K  -
MyPool/Test@Snap3     0B      -      304K  -
MyPool/Test@Snap4     0B      -      304K  -
MyPool/Test@Snap5     0B      -      304K  -
MyPool/Test@Snap6     0B      -      304K  -

Include any warning/errors/backtraces from the system logs

[stale]

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.

[GenericRikka]

I was able to confirm the unsorted error message on artix-6.6.34-1-lts by compiling from source on the main branch. If 4 snapshots of a test dataset were created and named by creation time, the output of zfs destroy zroot/test (using the freshly compiled binary) is still

use '-r' to destroy the following datasets:
zroot/test@3
zroot/test@4
zroot/test@2
zroot/test@1 

The unsorted list seems to be pulled and printed at line 1381 in cmd/zfs/zfs_main.c
I will have a look at it and see what i can do to fix this. Will keep you updated.

[GenericRikka]

Okay, sorry for the long pause, i have some private stuff going on that is slowing me down a lot. Anyways i read through some of the code and the line i mentioned earlier (line 1381 in zfs_main.c) is calling destroy_print_snapshots, which in turn is calling zfs_iter_snapshots_sorted_v2 which utilizes zfs_snapshot_compare from libzfs_iter.c which already sorts snapshots by creation time, so probably somewhere while passing the sorted list of snapshots they get unsorted. I will look further into it. This is indeed a good first issue, since i am slowly starting to become familiar with the Source Tree!

[Artem-OSSRevival]

Hi there. I am Artem from OSS Revival. If no one is mind, I will deal with this issue.