NULL node->children passed to hash_lookup about fuse-overlayfs HOT 5 CLOSED

do you have a quick reproducer that I could use?

pnode->children should be NULL only for files, so I'd need to investigate why it is used as a directory.

from fuse-overlayfs.

I can't say that it's quick, but what I did was check out the openwrt git tree, use that as the lower layer, and ran "make". While I made a custom build configuration, perhaps the default one will also trigger the case. Is there any kind of tracing I could turn on in fuse-overlayfs? I didn't happen to see any in the code when I looked, but I didn't look very hard.

from fuse-overlayfs.

no, there is no tracing that can be enabled.

Are all the layers on the same file system? I wonder if the issue could be caused by seeing the same ino in different places.

from fuse-overlayfs.

Indeed, the layers are on different FSes; they're all backed by ZFS, but the lower layer is on its own FS (for ease of snapshotting and backup) while the upper and work directories are on a common FS (intended to be more or less ephemeral).

from fuse-overlayfs.

I think I know what happens. The same ino is present on two different layers, pointing to different things. It confuses fuse-overlayfs. I've opened a PR to include the st_dev as part of the key: #113

I am not able to reproduce the issue locally, would you be able to try out the patch and let me know if it works for you?

from fuse-overlayfs.