root@nickserver:~# ln -sf /mnt/user/fakeCache/ /mnt/cache

root@nickserver:~# ls -lh /mnt

<hang>

 

Other terminals report

/boot/spin_drives.sh: fork: retry: No child processes

/boot/spin_drives.sh: fork: retry: Resource temporarily unavailable

...etc

 

(I was trying to keep all my dockers and systems working from a backup copy while I fixed an issue with my cache disks)

You do realize that /mnt/cache is referenced by the /mnt/user shfs mount, right? You just created a circular reference of infinite recursion. Nice job finding that there's actually a bug, though. It should probably detect and prevent infinite recursion like that.

 

Now, if you symlinked a share from user0 to cache, that might not cause infinite recursion, since cache doesn't live inside user0.

 

Of course, if you were to unmount one of the diskN points while the array was up, and remove its directory, then symlink a subdirectory of /mnt/user0 to that diskN path, it would probably fail as well.

If my recollection is correct, cache is mounted under user at /mnt/user/cache

 

If I'd symlinked

/mnt/cache -> /mnt/user/cache/something

maybe we'd have a problem, but as I wrote it I don't think there's any circular reference

No. The cache mount is /mnt/cache, not /mnt/user/cache. In fact, the WebUI will not allow you to create a share named "cache", being among several reserved names. Nothing stopping you from mkdir:ing a folder under /mnt/user and creating a share that way, though.

 

/mnt/user sums up the contents of all the mounted /mnt/diskN folders, as well as /mnt/cache. /mnt/user0 sums up only the numbered diskN mounts.

 

To symlink something underneath /mnt/user to /mnt/cache causes the proprietary shfs fuse module/process to traverse inside /mnt/cache the instant something attempts to access or count the file size of /mnt/user. Traversing inside /mnt/cache then follows the symlink to /mnt/user/something, which then attempts to traverse the /mnt/cache link again, infinitely, until you forcibly reboot the machine.

 

Suggested fix/check: shfs daemon, when encountering a symlink either as one of its watch points, or within one of its watch points, ignores it if it links to the target file system. Also, it should keep an eye out for circular links within the systems, so that same or higher level folders or files are not indexed repeatedly, which sounds like a job for deduplication.

You're right, I was remembering incorrectly

 

Still, probably shouldn't crash the system

It isn't crashing the system, not immediately, that is. It's live locking the kernel in an infinite recursion, presumably until it runs out of stack space. Then it's crashing. Clearly special cases they did not consider.

Suggested fix/check: shfs daemon, when encountering a symlink either as one of its watch points, or within one of its watch points, ignores it if it links to the target file system. Also, it should keep an eye out for circular links within the systems, so that same or higher level folders or files are not indexed repeatedly, which sounds like a job for deduplication.

I'll look at that.