ZFS Clarification on "filename path" limitation for ZFS snapshot mounts in 11.xR, until ino64 lands

[Stilez]

This question is related to the 63-or-88 char limit on mount paths as it affects ZFS snapshots, this 11.1R part-resolution in r319096, this issue + this.

To recap as I understand it, up to 11.0R, file system actions that implicitly needed to mount ZFS snapshots were limited by statfs's fixed 63+88 byte limits, so ls -1R or find . -name couldn't always be used as normal on a ZFS pool with snapshots in some cases (they errored out midway: fts_read returned "no such file or dir"). This was part-fixed by r319096 in 11.1R so that at least in some cases they wouldn't error out. The full fix is only present in ino64 which increases the limits to 1024 chars, but ino64 is only scheduled to land with 12R in 2019.

As 12R won't be here for a while, this issue is still relevant. I can't currently search files on my filesystem because I didn't know about this issue when I set it up. That's not a problem (rename+delete solves everything!) but I'm not clear what exactly constitutes the relevant "filesystem paths" which must be kept under 63-or-88 chars respectively, to avoid this issue until 12R, particularly for ZFS pools contains nested datasets.

A definitive "this is how to determine whether a zfs dataset or snapshot will trigger this issue when mounted by ls or find", would really help.

Below is a concrete example showing the kind of issue I have:

1. I have ZFS on 11.0R. The pool contains nested datasets and non-hidden snapshot dirs (to allow normal searching). Example: a pool might contain nested datasets tank/production_northwest/public_files/marketing/2017 - then only ordinary files+dirs below "2017". I have some snapshots set up on tank, and perhaps also some manual snapshots I've added on public_files or 2017.
2. If I now use a command like find /mnt/tank/production-northwest -name "somefile*.docx" to find all copies of some file (including snapshot copies) then this command fails because of the above bug, because the file system hierarchy contains nested snap dirs such as .zfs/snapshot/manualsnap_20171030-130000 both on the root dataset and the lower level nested datasets. When find tries to traverse these, it first implicitly mounts them. The implicit mount fails, and find errors out. Effectively I can't ls -1tR or find.

The issue is clear to me. How to fix it is also clear to me (rename datasets/snaps as needed, or delete some snaps). What I'm not clear about - as I said above - is exactly what, in this scenario of nested datasets and snapshots, constitutes the "filesystem paths" that I have to keep below "63-or-88" chars in 11.0R or 11.1R, and what exactly now works in 11.1R that didn't work in 11.0R (i.e., whether the rename/deletes needed to fix find and ls in 11.1R are the same as in 11.0R given the r319096 patch).

Can someone who is clear about it, give me a definitive explanation of the criteria, and a few examples to make sure it's clear (perhaps based on my example filesystem above), and make clear what exact combination of path and name lengths must be kept short to make my file system searchable again

Thanks!