Open isarandi opened 5 years ago
I had a problem related to symlinks, but when you mount using then.
for example, if you mount a backend filesystem mounted on /tmp/backend to /atomo, but /atomo is actually a symlink to /RAID/atomo.
mcachefs /tmp/backend /atomo
When I first did that, something weird happened, and mcachefs got into a weird never-ending loop which made my machine load average
plumb to 9000 after a few minutes!
it was fixed by calling:
mcachefs /tmp/backed /RAID/atomo
using the actual path the /atomo symbolic link pointed to (/RAID/atomo) instead of the symlink.
not sure if there's something to do with your problem, but I thought it was a relevant piece of info anyways...
so... KIDS, never mount mcachefs to a symlink!!
@isarandi Could you please share your usecase, more information on your symlink content ?
I assume that's an absolute symlink within the backend filesystem, or at least a relative one pointing outside of the scope of the backend filesystem. This should imply mcachefs is able to transform the backend symlink to a locally-understandable symlink. Which it doesn't.
Otherwise, purely relative symlinks do work, if they are relative and inside of in the backend mount point. For example, if I have a folder 'a' and a symlink 'b' pointing to 'a', this symlink will be displayed and resolved correctly on the local filesystem as well.
On the remote machine the content is mounted via NFS from a third machine. The symlink was absolute I think (but I don't remember exactly), pointing back to a different directory of the same NFS mount. The NFS mount is mounted directly one level under the root.
I'm using mcachefs to cache sshfs. The sshfs option follow_symlinks enables me to traverse symlinks on the actual sshfs mount. However the mcachefs cached mount says "cannot read symbolic link h36m: Invalid argument".