Permissions inconsistent with actual filesystem about mergerfs HOT 4 CLOSED

I can actually reliably reproduce this with another user on this machine (that is, I consistently get EACCESS from the pool, but it works fine from the drive directly). Syscalls are the same, though... 🤔

from mergerfs.

Are you interacting with the filesystem before doing all that?

mergerfs has a supplemental group cache because the cost of looking up supplemental groups is pretty expensive.

https://github.com/trapexit/mergerfs#supplemental-user-groups

And every thread has its own cache. So my bet is you have triggered the cache at different states of setup and so you get different results. Restart mergerfs and I would suspect it works as expected.

It is on my todo list to add an occasional timing out of the caches but right now it doesn't do that since changing of groups is pretty rare. The description there needs some updating but I was holding off till I added a timeout to the cache. At the end of the day though it will never be 100% because there is no way to know the grouping changed to invalidate and it is too expensive to check regularly. Best I can really do is a general timeout and/or manual flushing.

from mergerfs.

Thanks, it looks like this was the culprit.

On an unrelated note (unless you'd rather me ask in a new issue): I copied a large amount of data to this pool using rsync, with the above mergerfs settings, and two drives of equal capacity. Somehow, an entire directory's worth (let's call it /a) of files ended up on just one drive, but an /a directory on the second drive was created, which is empty. Does this sound normal? I don't understand how such a thing would happen -- why would an empty /a directory be created, if no file was put there?

I don't know why this would be the case, it's not like rsync is parallel. Furthermore, if I just mkdir /pool/b, /b only gets created on one drive. So... not sure why this would be happening.

(Hopefully that makes sense; it's not that big of an issue, just a curiosity if anything.)

from mergerfs.

Without a more explicit description of exactly what the original state is and what actions are taken I can't really speak to it.

Everything works as described in the docs. If you have category.create=mfs then the branch with the most free space is chosen for the function in question.

from mergerfs.