Unpredictable Behavior when Upperdir is also Mountpoint about fuse-overlayfs HOT 5 OPEN

In general, actually, I don't think this really has anything to do with any of the directories being the same, but probably more specifically, the mountpoint being not empty.

I think the upperdir being the same as the mountpoint might have simply uncovered most of the odd behavior.

from fuse-overlayfs.

I think maybe the application that can't find the file still hold the old fd of the upperdir/mountpoint? IMHO it should be ok for overlayfs (both overlayfs-in-kernel and fuse-overlayfs) to use the upperdir or lowdir or any other non-empty directory as the mountpoint...

Before mounting, we'll get the origin fd of the upperdir when we open the upperdir by path. And after mounting, we would follow/traverse the mount and get the root of overlayfs intead when we open the same path. They are totally different objects in kernel (file/dentry/inode/fs), even though they are opened through the same path/name...

The overlayfs will open directoris of all layers and hold their fd for further access, like writting file to upper-layer, but the user application should drop the origin fd and switch to the new upperdir, then access the newly mounted file system.

from fuse-overlayfs.

I agree, it definitely should be a supported Use Case. If this use case was properly supported, though, it would not necessarily matter if they were holding on to the old fd, given that fuse-overlayfs should be propagating the changes in bother the upperdir and mountdir appropriately. In other words, writes to the mountdir should propagate to the upperdir, and changes to the upperdir should be adequately reconciled to the mountdir. This is a complicated mechanism, but it needs attention in this case.

Regardless, unfortunately my extensive testing has shown that the application(s) are not holding onto the old fd of the upperdir/mountpoint. This can be reproduced by mounting the overlayfs at startup before any of the applications that are using the mount point interact with the file system.

Applications opened after the fact still result in corruption of files. I'm actually still uncovering file corruption that's occurred last month on an actively used machine for various applications and purposes. That's definitely concerning and points to some instability in the way that fuse-overlayfs is currently reconciling changes between the mountdir and upperdir.

from fuse-overlayfs.