"Minimum Free Disk Space" setting not working/respected?


#1

I read through the support forum and checked the document at https://docs.syncthing.net/users/config.html#folder-element, however, I need further clarification or perhaps guidance as I may be configuring my instance of syncthing for android incorrectly…

I have SyncTrayzor v1.1.22/Syncthing v0.14.51 running on my Windows 10 Pro 64-bit PC at home. A folder I have shared on it contains about 500GB of media.

I have a Pixel 2 XL running the Syncthing v0.14.50 app with a folder on its internal storage sync’d to said shared folder from home PC mentioned above…with conditions to only sync on certain wifi AND AC power.

Syncing works well, however, my issue is that Minimum Free Disk Space setting doesn’t seem to be respected…this is where I assume I possibly am understanding the setting incorrectly or have it set up incorrectly…

In the app on the phone, there are two locations to adjust the Minimum Free Disk Space that I can see. One is under the gear icon on main WEBUI and the other is under the Advance section in the edit menu of the folder being sync’d.

My phone is advertised as the 128GB model (110GB usable). Of this internal capacity, I have roughly 80GB free…The default value for both of the Minimum Free Disk Space settings in the Syncthing app was 1%; is this 1% of the usable 110GB or 1% of the 80GB free space? Anyways, I want there to be a total of about 5GB of free space left on the phone after all the syncing (which obviously I understand you can’t fit 500GB into 80GB and thus syncing stops until more free space is made available), which setting should I change the folder or the one in the main setting…or both?

I’ve attempted various values in percentages and absolute values in MB and GB yet when I wake up in the morning I have a notification on my phone of low disk space and Google play services among others keep crashing due to this…generally left with anywhere from 49 MB or less to maybe at most 120 MB or so…

I mainly use this setup as an on the go media library; as I watch my media on my phone I delete them thus clearing space on my home PC and all the while the phone is refilled at night with new content.

Suggestions greatly appreciated!


(Simon) #2

That sounds like the free disk check doesn’t work (probably because Android), in which case it is skipped, i.e. assumed there is enough space. In general it is more of a “fail-safe” than a mechanism to manage how much data to sync. A pretty much random subset of your 500GB will be synced and Syncthing will be constantly out of sync. Better options are to share just the directories you really want or set up ignore patterns to the same effect.


#3

ah, it must just be broke as you said, probably because Android… I actually want everything in that ~500GB so the sharing only certain directories doesn’t apply to my use case (it is 1 directory). I was trying to use this mechanism as a constant queue on the phone…watch, delete, sync new episodes/movies. I was doing it the tedious way via USB cable previously…aside from the free disk space issue the syncthing method is the way to go. I generally resolve my low disk by cleaning up temp/cache/thumbnails…enough for normal use of the phone, watch at least 1 video to delete for added buffer then be set til next sync overnight. Thanks for the input!


#4

It works as expected on my Pixel (1) with Android 9.

System settings say I have 89.86GB free. If I set the minimum free space of one folder to 91 GB, it stops and displays a warning for low disk space.

But if I set it to 90GB, it doesn’t. Can it be, that the size check really uses GB, not GiB. With 91 GB set, is show 90007007232 < 91GB. But 90007007232 Bytes are 83.83 GiB, so 90 should work as well.

The main free disk space setting “kills” syncthing completely, as the DB could be corrupted, if there is not enough space.


#5

OK, so do you recommend switching the main setting back to default 1% and just play with values for the folder’s setting some more?


#6

Yes. Try settings the free space for the folder to something higher than you currently have free with an absolute unit, not %. There should then be a warning immediately.


#7

Main setting back to 1% as if untouched and changed the folder setting. It behaves as your stated, I only have 2.30GB free space currently to play with so I set the Minimum Free Disk Space for the folder to 3.0GB and received the insufficient space error. To test, I adjusted it to a minimum of 1.5GB of free space, it is currently syncing… Waiting to see if it stops at 1.5 or thereabouts or if it continues to sync past it (which has been my case so far).


#8

…it went past the 1.5GB minimum threshold and I am now currently at 0.94GB at which point I unplugged from AC to break the sync conditions…


(Simon) #9

Yep, you just found a “bug” which is already fixed in 0.14.51. In parentheses because it was working as expected, which wasn’t perfect. The check was done at the beginning of synchronization. During the synchronization, it wasn’t checked anymore.

@AudriusButkevicius Would it be possible to make a new release of the app, to get the new Syncthing version to users? Probably worth waiting another week with it anyway for v0.14.52.


#10

AWESOME! Great to know it’s fixed in an upcoming release and that I’m not crazy or configuring something incorrectly. Thank you for the update!


(Audrius Butkevicius) #11

I am living out if a suitcase with no proper pc access. Someone needs to merge the rc to the main branch, and re-release as non-rc.


#12

I don’t think this is fixed in 0.14.51.

I just tested with 0.14.51 on linux. minimum on one folder set to 35% or 75 GB or 82 GB, syncthing happily syncs newly created files from the remote device, even though

$ df
...
/dev/dm-0    221562228    140972048    69265740    68%    /
...

Only with minimum set to 83 GB or higher, the folder gets out of sync with failed items because of insufficient space.


(Simon) #13

That’s indeed weird, but a different issue: It looks like a limit is applied, even during pull (that’s what I was referring to as being fixed), but the limit is off. Are your tests still consistent with this potentially being a binary vs base10 issue?


#14

The tests on linux don’t add up with binary vs base10, so it must be something else.


(system) #15

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.