.zfs folder's missing, but snapshots are still there and mountable (inode trouble?)

Question

$ sudo zfs list -t snapshot | grep childDataset3

a whole bunch are listed as expected (e.g. pool/dataset/childDataset3@today)

$ ls /pool/dataset/childDataset3/.zfs
ls: cannot access '/pool/dataset/childDataset3/.zfs': No such file or directory

I have other child datasets, and I can see the snapshot dir inside .zfs for them; and, I can even mount a snapshot from the above list from the one troublesome dataset (so they exist, just not as a nice list in a normal spot that users can dip into):

$ sudo mkdir /mnt/tempShadow
$ sudo mount -t zfs pool/dataset/childDataset3@today /mnt/tempShadow

i.e. I can browse one snapshot of files this way; also noteworthy, when I run the disk filesystems command with show inodes, all of the working datasets and child datasets show up EXCEPT for the one I'm having trouble with (what I'm calling "childDataset3"):

$ df -i

pool                               232594013966       9 232594013957    1% /pool
pool/dataset                       232600679652 6665695 232594013957    1% /pool/dataset
pool/dataset/childDataset1         232596006126 1992169 232594013957    1% /pool/dataset/childDataset1
pool/dataset/childDataset2         232594839509  825552 232594013957    1% /pool/dataset/childDataset2
pool/dataset/childDataset4         230211379723 3040916 230208338807    1% /pool/dataset/childDataset4

so is there a way to re-create the child dataset's inode? (forgive me if I'm totally saying that wrong)

using zfs version 0.7.12-2+deb10u2 if that matters

my backup solution is to switch users to the replicated dataset (on another server), and then destroy this dataset, then send a snapshot back (but I want to avoid this, because 32TB doesn't just pop over)

Answer 1

The .zfs directory is special: try to first chdir into it and then listing it.

In other words: cd /pool/dataset/childDataset3/.zfs/ ; ls

Answer 2

since it doesn't seem like anyone has an answer (or they do, but just not finding my post), I'll answer my question:

note that albeit new snapshots are being made on this glitched child dataset, and I can at least mount those snapshots (albeit can't browse .zfs/snapshot)... ...when I look through said mount, I now see that new files are not there, and the snapshots are taking up 0B of space, and zfs list is not showing that the used space is growing (like "du -s /pool/dataset/childDataset3" would)

and, if I "sudo zfs rename pool/dataset/childDataset3 pool/dataset/childDataset3-bad", the /pool/dataset/childDataset3 folder is still there with all the data, and path /pool/dataset/childDataset3-bad doesn't exist, albeit zfs thinks it exists and consuming space; i.e. my problem is that somehow a folder and dataset are existing together (like when you create a new dataset with the folder existing already: you get a not empty error and can easily re-create the glitch I'm experiencing)

SOLUTION: rename the bogus dataset, destroy the bogus dataset, create a new dataset (same old name you used before for the bogus one), and move the data back (using rsync and remove source flag):

ATTN: if you get an error moving (aka renaming) the folder, then you do not have the same problem as I did (do NOT destroy your dataset if the mv command results in an error)

mv /pool/dataset/childDataset3 /pool/dataset/childDataset3-folder
sudo zfs destroy -r pool/dataset/childDataset3
sudo zfs create pool/dataset/childDataset
sudo chown yourUsername /pool/dataset/childDataset
rsync -auAXv --remove-source-files /pool/dataset/childDataset3-folder/ /pool/dataset/childDataset3/ > moveLogs.txt &
# I had to wait a couple weeks (I'm copying 50TB)
find /pool/dataset/childDataset3-folder -empty -type d -delete
# you can run the above find command whenever, and when rsync is done, the find command will remove childDataset3-folder (and if you rsync bails, you can re-run that too)

DISCLAIMER: please understand what you're doing when you run a command like destroy, especially with recursive (or use --remove-source-files in rsync); I'm also assuming no one is using the bad dataset (nor is it involved in something like a backup)