syncthingfuse
syncthingfuse copied to clipboard
burkemw3
Sometimes there is an error unmounting ~/SyncthingFUSE on exit
After running syncthingfuse, changing config, restarting it some times, everything was going ok, until I tried to change the cache size of a folder from "512 MiB" to "1 MiB". syncthingfuse asked me to restart, so I did, but then it failed to start with the following:
[SHPVK] 16:24:18 INFO: Started syncthingfuse v. unknown-dev
[SHPVK] 16:24:18 INFO: My ID: SHPVKE2-OO642WM-35QOY7X-DQ2WWTP-FAWRM33-3EI6GWZ-PKFZ5LZ-V26Y6AC
[SHPVK] 16:24:18 INFO: Mount point ( /home/fiatjaf/SyncthingFUSE ) does not exist, creating it
[SHPVK] 16:24:18 FATAL: Error creating mount point /home/fiatjaf/SyncthingFUSE mkdir /home/fiatjaf/SyncthingFUSE: file exists
I then tried to manually edit config.xml, setting the cache size of the folder to "2 MiB", "10 MiB" and finally "512 MiB". the problem persists.
It is worth noting that the actual size of the ~/SyncthingFUSE directory was somewhat larger than 1 MiB, perhaps larger than 20 MiB, but not larger than 512 MiB (I don't know, but it seems all the files from the shared folder were automatically downloaded because their total size was below 512 MiB? Or none of them was downloaded, being their appearance in the directory a FUSE trick?).
Also, before changing the cache size I successfully opened one small text file on ~/SyncthingFUSE.
Ok, the error is on os.Stat on https://github.com/burkemw3/syncthingfuse/blob/1f89e1b0079ecae0f362141b247f8db382672f1a/cmd/syncthingfuse/main.go#L94
Logging it gives:
2016/01/16 16:52:26 stat /home/fiatjaf/SyncthingFUSE: transport endpoint is not connected
This typically is caused by the mount directory being left mounted due to a crash of your filesystem. (http://stackoverflow.com/a/29400722/973380)
fusermount -u ~/SyncthingFUSE made it work again.
Now that I know this, I looked again at the logs from ending syncthingfuse the time it was breaken. It had:
[SHPVK] 16:23:30 INFO: Unmounting...
[SHPVK] 16:23:30 INFO: Unmount failed: exit status 1
[SHPVK] 16:23:30 INFO: syncthing FUSE process ending.
[SHPVK] 16:23:30 OK: Exiting
Now I tried exiting again and it succeeded:
[SHPVK] 16:57:14 INFO: Unmounting...
[SHPVK] 16:57:14 INFO: Unmounted
[SHPVK] 16:57:14 INFO: syncthing FUSE process ending.
[SHPVK] 16:57:14 OK: Exiting
I don't know what could have caused the umount problem at that time. It could be anything. I know nothing about FUSE, but searching over the internet I found this GitHub comment which points to this brute force anti-race umount code.
Also, it uses this FUSE library. Could it be helpful somehow?
I have also occasionally seen issues creating the mount that have been resolved by forcing an unmount (e.g. fusermount -u ~/SyncthingFUSE).
Good digging to fund the brute-force unmount loop! That could be useful!
SyncthingFUSE is currently using the bazil.org fuse library.
Regarding the size of the SyncthingFUSE files, there is certainly a FUSE trick being played. The files will appear to be their full sizes, but that full data isn't stored on disk. The data is stored on disk alongside the config file (probably in $HOME/.config/SyncthingFUSE/ on linux).
Since you tagged this as a bug, I'll rename the issue to reflect the actual bug.
New information (for me, because you FUSE hackers probably already knew it): if a the directory under the FUSE mountpoint (~/SyncthingFUSE) is opened in the computer, either in the shell or by a window GUI, the unmount will fail. Is that correct?
If yes, then the problem is fairly common, there should be a solution.
I haven't found enough info on lazy unmounts to be confident this is the right fix. In addition, I'd like to see something to resolve similar problems on OSX.
For some reason, I don't hate the brute force anti-race umount code.
Unfortunately, I am not able to look at this more deeply for a couple more weeks.
No problem. Feel free to close this. No hard feelings.
I did some manual tests on Linux and it worked quite well. Tried to search for something analogous on OSX, but couldn't find anything.
Finally got some time to look at this. As mentioned in the commit, I was able to reproduce the issue more frequently under certain circumstances.
The change I made is preventing the issue, in my testing, on my OS X box.
Binaries including this change are available here. Let me know how these binaries do! If they look good, I'll create another github release. (I haven't figured out any management or process between gobuilder.me and GitHub releases right now.)
(As if to taunt us, Qi wrote about a similar deal this week.)
I'll try the binaries soon. Thank you for looking at it.
(What is this Qi thing? Is this something all programmers read and I'm not aware?)
(The Qi thing is a collection of short stories about programming. It's something I read, but not something all programmers read, by an stretch.)