zdb gets confused by datasets starting with numbers

[rincebrain]

System information

Type	Version/Name
Distribution Name	Debian
Distribution Version	11
Kernel Version	5.10.0-9-amd64
Architecture	x86_64
OpenZFS Version	c9d62d1 or so

Describe the problem you're observing

(I'll go figure out a "correct" handling for this later, I just wanted to mention it in case I forgot after I ran into it...)

I tried to examine a child dataset under a dataset named "1M", at the top of a pool, "lz4newtestpool".

# sudo zdb -dbdbdbdbdbdb lz4newtestpool/1M/largefiles 256
failed to hold objset 1: Invalid argument
zdb: can't open 'lz4newtestpool/1M/largefiles': Invalid argument

But if I rename 1M to sigh1M, it works as expected.

I would presume this is due to:

zfs/cmd/zdb/zdb.c

Lines 8525 to 8539 in 510885a

	char *endptr;
	errno = 0;
	objset_id = strtoull(objset_str, &endptr, 0);
	/* dataset 0 is the same as opening the pool */
	if (errno == 0 && endptr != objset_str &&
	objset_id != 0) {
	target_is_spa = B_FALSE;
	dataset_lookup = B_TRUE;
	} else if (objset_id != 0) {
	printf("failed to open objset %s "
	"%llu %s", objset_str,
	(u_longlong_t)objset_id,
	strerror(errno));
	exit(1);
	}

since patching the second check to not exit(1) and reset objset_id to -1 allows us to proceed, albeit having printed the error.

Describe how to reproduce the problem

sudo zdb -d pool/1zzz

Include any warning/errors/backtraces from the system logs

GOTO 10

[PaulZ-98]

It turns out that the -d /dataset | objsetID is not going to be a good zdb command line interface for using the numeric objset id, for the reason you're seeing. stroull will convert 1M to 1 and then not find it. Also tank/100 is a valid dataset name so it's ambiguous if you want it to be an objsetID or dataset name string.

I had originally done

zdb tank -N 236:2   (objset:object)

but we didn't go with that. Now we have objectID ranges to consider if we adopt a ":" separator. Ideas welcome.

[rincebrain]

I'd probably opt for a variant of that, really - something like zdb tank -N 236 [object or range[,...]], since I don't think it's ever currently legal to specify multiple datasets no matter how you phrase it, and if it were, then we could (ew) go for positional-based parsing where it affects later arguments?

I'd still prefer it if the existing logic did something like "try as path name" => "if it fails, try as objsetid", and then you can unambiguously specify it if you need to? (Mostly in that order because I think people are more likely to run into the case of "I have a dataset named 100 and want to reference it when there's an objsetid 100" than "I have an objsetid 100 and there's a dataset named 100 i wanted to reference instead".)

[PaulZ-98]

I'll work on getting the "try as dataset name" => "if it fails and (if numeric looking), try as objsetID" working. Also the way it uses args[2] is wrong and won't work if you have other args so I'm already fixing that.