Syncthing problem

[jiakai1000]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is.
I have 2 hard drives, mounted at /mnt/a and /mnt/b, and mounted at /var/lib/backup with mergerfs. I ran Syncthing to backup all data in /var/lib/backup to another NAS. Syncthing created a folder named .stfolder, if this folder lost(maybe drive fails), Syncthing will stop sync and report error. The problem is: if .stfolder is in /mnt/a, but drive /mnt/b fails, Syncthing think some data is removed(files in /mnt/b) normally and it will remove remote backup !
Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

[trapexit]

I don't understand what you're reporting / asking.

[jiakai1000]

I am very sorry that my English is not good, so I can only use translation software to describe my problem.
I have two hard disks in my NAS, mount to /mnt/a and /mnt/b, and then mount them to /var/lib/backup using mergerfs. I use Syncthing to automatically synchronize my data on it to another NAS. Syncthing will create a directory called .stfolder, If hard drive fails, the .stfolder will be missing, and Syncthing will stop synchronizing.
My question is: If the .stfolder is saved in /mnt/a, but /mnt/b mount fails due to disk corruption, mergerfs will still run normally, but the files in /mnt/b have been lost and the .stfolder is still there, so Syncthing will not notice anything unusual. These files are considered to be deleted on purpose and are automatically synchronized to the remote NAS. As a result, the backup files on the remote are also deleted. I would like to ask if there is a way to solve this problem, thank you very much!

[trapexit]

Use backups? Use snapraid? Don't use mergerfs? Use RAID5 or 6?

mergerfs doesnt provide redundancy. The whole point of the software is to combine entirely separate filesystems. With that comes the possibility of logically split failure like you described.

[jiakai1000]

I don't want to use RAID, I just want to maximize space usage, and I don't worry about losing data because I have multiple backups, and this is just one of them. I also don't want to use LVM, because any disk failure will result in the loss of all data. So mergerfs is a great choice.
Could you add an option to force all branches to be mount points instead of a normal directory? If the /mnt/b mount fails, mergerfs also fails. That way Syncthing will know about the error.

[trapexit]

It's not that simple. mounts can disappear at any time so it would have to actively monitor the branch to see if it changes. And it isn't free to monitor the filesystem at runtime. In the least it would cause the filesystem to be constantly accessed which could be a concern with network filesystems or spindown of harddrives. Also, what is to be done when it is noticed? Exit? That could cause data loss or programs to behave poorly.

I certainly could add a feature to check if branches are the same as the parent path and fail to mount. Though it wouldn't be foolproof given the main identifiers for a filesystem aren't always unique. Particularly with FUSE filesystems. Also it wouldn't be a comprehensive solution.