Hi, the 'bectl list -c origin' commands throws me a 'Bus error' as output. $ bectl list -c origin Bus error $ bectl list -C origin Bus error While -c name works properly. $ bectl list -c name BE Active Mountpoint Space Created 13.1-RELEASE NR / 24.4G 2022-06-02 22:17 13.1-RELEASE.safe - - 1.07G 2022-09-15 10:41 This is on FreeBSD 13.1-RELEASE. % uname -v FreeBSD 13.1-RELEASE releng/13.1-n250148-fc952ac2212 GENERIC Regards.
Not reproducible with 14.0-CURRENT, and (at a glance) <https://cgit.freebsd.org/src/log/?qt=grep&q=bectl> I see nothing related in main. kevans@ any idea? (In reply to Slawomir Wojciech Wojtczak from comment #0) A wild guess, the '.' caught my eye, but does not cause an issue here: root@mowa219-gjp4-8570p-freebsd:~ # uname -KU 1400073 1400073 root@mowa219-gjp4-8570p-freebsd:~ # bectl list -c origin BE Active Mountpoint Space Created n256570-5c19fabbe34-f - - 6.49G 2022-07-22 21:06 n257645-160a2f2cdda-b - - 11.7G 2022-08-29 15:49 n258027-c9baa974717-d - - 10.2G 2022-09-28 08:46 n258900-aba921bd9e1-a - - 4.65G 2022-10-29 17:40 n258900-aba921bd9e1-b - - 118M 2022-11-01 08:59 n259004-2c10be9e06d-a - - 120M 2022-11-03 03:42 n259004-2c10be9e06d-b - - 556M 2022-11-03 17:47 n259004-2c10be9e06d-c - - 503M 2022-11-08 21:54 n259004-2c10be9e06d-d - - 254M 2022-11-14 01:06 n259004-2c10be9e06d-e - - 245M 2022-11-15 07:21 n259004-2c10be9e06d-f - - 307M 2022-11-18 07:14 n259004-2c10be9e06d-g - - 327M 2022-11-22 00:49 n259004-2c10be9e06d-h - - 200M 2022-11-25 16:26 n259004-2c10be9e06d-i - - 64.0M 2022-11-28 22:27 n259461-f4d3aa74908-b NR / 293G 2022-12-02 08:10 n259461-f4d3aa74908-a - - 64.9M 2022-12-01 06:08 root@mowa219-gjp4-8570p-freebsd:~ # bectl create blah.blah root@mowa219-gjp4-8570p-freebsd:~ # bectl list -c origin BE Active Mountpoint Space Created n256570-5c19fabbe34-f - - 6.49G 2022-07-22 21:06 n257645-160a2f2cdda-b - - 11.7G 2022-08-29 15:49 n258027-c9baa974717-d - - 10.2G 2022-09-28 08:46 n258900-aba921bd9e1-a - - 4.65G 2022-10-29 17:40 n258900-aba921bd9e1-b - - 118M 2022-11-01 08:59 n259004-2c10be9e06d-a - - 120M 2022-11-03 03:42 n259004-2c10be9e06d-b - - 556M 2022-11-03 17:47 n259004-2c10be9e06d-c - - 503M 2022-11-08 21:54 n259004-2c10be9e06d-d - - 254M 2022-11-14 01:06 n259004-2c10be9e06d-e - - 245M 2022-11-15 07:21 n259004-2c10be9e06d-f - - 307M 2022-11-18 07:14 n259004-2c10be9e06d-g - - 327M 2022-11-22 00:49 n259004-2c10be9e06d-h - - 200M 2022-11-25 16:26 n259004-2c10be9e06d-i - - 64.0M 2022-11-28 22:27 n259461-f4d3aa74908-b NR / 293G 2022-12-02 08:10 n259461-f4d3aa74908-a - - 64.9M 2022-12-01 06:08 blah.blah - - 8K 2022-12-05 03:53 root@mowa219-gjp4-8570p-freebsd:~ # bectl destroy blah.blah root@mowa219-gjp4-8570p-freebsd:~ #
(In reply to Graham Perrin from comment #1) It seems to still be a problem on -HEAD, though we're getting a lot luckier there. Something like this works around it, but I haven't decided on the proper solution yet: diff --git a/sbin/bectl/bectl_list.c b/sbin/bectl/bectl_list.c index e43c3000d8f..7ea958a3e38 100644 --- a/sbin/bectl/bectl_list.c +++ b/sbin/bectl/bectl_list.c @@ -347,7 +347,7 @@ prop_list_sort(nvlist_t *props, char *property, bool reverse) { nvpair_t *nvp; nvlist_t *nvl; - int i, nvp_count; + int error, i, nvp_count; uint64_t lval, rval; struct sort_column sc_prev, sc_next; @@ -360,7 +360,9 @@ prop_list_sort(nvlist_t *props, char *property, bool reverse) nvp = nvlist_next_nvpair(nvl, NULL); nvpair_value_nvlist(nvp, &sc_prev.nvl); nvlist_lookup_string(sc_prev.nvl, "name", &sc_prev.name); - nvlist_lookup_string(sc_prev.nvl, property, &sc_prev.val); + error = nvlist_lookup_string(sc_prev.nvl, property, &sc_prev.val); + if (error == ENOENT) + continue; while ((nvp = nvlist_next_nvpair(nvl, nvp)) != NULL) { It's basically just that one dataset doesn't have 'origin' set, but we don't actually check that the sort property we're looking up exists.
(In reply to Kyle Evans from comment #2) I think the correct answer is going to be that we should just treat missing values as an empty string.