Continuing the discussion from Performance issues under 1.4.0 rc4:
This is maybe the same issue as in Folder shows as "Up to Date" but global and local states do not match. There were db restorations and folder type changes involve, at least the former doesn’t apply here as far as I know.
A few questions:
Previous versions were ok. I should have the total local state closer to 7Tb, but as yet it’s not yet fully indexed all the folders, so it’s still showing this
It appears to only be the receive only folders that show wrong figures. I checked the send only jobs and they appear to be reporting the folder / file sizes correctly. Interestingly, the first snip where it shows 1.81Tb global, the send only end shows this…
And I checked the actual folder and the figures tally. So it may be a misreporting issue and is ok (hence the ‘up to date’), just the figures are wrong, perhaps this is why my total (local state) is so low.
Folder types have always send (remote) receive (here)
Just reading Folder shows as “Up to Date” but global and local states do not match. There’s mention of database resets. On the ‘receive only’ I had renamed the index folder as I wanted to downgrade and allowed it to rebuild and then come back to 1.4. I wonder if there is any merit in maybe doing the same thing on the remote computer to see if they then realign. It feels like there is some sort of doubling up on the number of files possibly caused by the index being wiped and rebuilt.
Please don’t do any re-setting right now, you might have found something tangible (and hopefully fixable here).
I understand this that the following to screenshots show the same folder on two devices:
And that the latter numbers are correct on the filesystem on both sides, as in:
On the receive-only side, is a Revert button displayed?
Can you query GET /rest/db/file — Syncthing documentation for any file on both sides please.
There is no revert button on either side
Receive side-
Send side-
The db file get might take a while as i’m trying to figure out how it works as all I get is csrf error
You probably use https? Then you need to pass Ups, stuck in my linux-bubble. See post below for windows advice.-k to curl.
This looks like Windows, so PowerShell and not curl may be in use here.
The following explanation helped me when I was learning how to call the REST API for the first time:
https://forum.syncthing.net/t/how-to-call-the-rest-api-from-windows-powershell/11269
Just try using https instead of http in the URL.
That worked and the xml’s PMed to Simon. Thanks for the heads up as I was really struggling
I spoke too soon. I followed the link / instructions verbatim not realising that the first section refered to a config export (which apparently worked). However when I try the following commands
$Url = “http://localhost:8384/rest/db/file?folder=i_use_the_folder_id&file=00b7974a-0000-0000-0000-00093d000000.vhdx”
$Headers = @{“X-API-KEY” = “edited”}
Invoke-RestMethod -Uri $Url -Headers $Headers -Method Get -Outfile response.xml
it fails with
I’ve tried it at both ends and get the same error so I must be missing something.
Sorry i’m going off on a tangent, but maybe this will help others in the future
The command itself is actually fine, it just responded that there is no such file (“No such object in the index”). Is the file actually in the folder root? If it’s in a sub-directory, you need to give the path relative to the root (e.g. file=foo/00b7974a-0000-0000-0000-00093d000000.vhdx).
Bit odd, some paths simply refused to work, some servers had too early a version of powershell to work, but eventually I was able to pull the files off a W10 box. They were on 1.4.0 rc2, but it was still a mismatched sync
I will send the files to simon
Thanks for your patience!
There was nothing wrong/special with the /rest/db/file outputs, no mismatching deletes at same version and everything valid and no local flags.
It looks like all files at first existed local only, i.e. with the receive only local flag. Then the remote came in, everything got updated fine in the db but in metadata we only added the new global and didn’t remove the old, receive only, file. However I don’t yet have an idea how that would happen.
Is it therefore worth resetting the remote (send only) db? or I could remove the affected folder and re-add it. Or sit tight and see if any future fixes it resolves it.?
No db resetting needed. You just need to recalculate metadata, which can be done by setting the STRECHECKDBEVERY environment var to 0. If you use Synctrayzor I believe there’s a setting to add env vars.
strecheckdbevery has solved the problem. The folders that were misreporting are now realigned
But also the performance issue that I have had for the last week (where the gui freezes and the disk queue goes very high) is also gone / back to normal.
CPU is high, but that’s to be expected as I still have folders to scan, but after 16 hours of uptime, last week I would be locked up, now it’s just plodding along
and the local state is starting to increment whereas it was stuck on 2.??TiB
Perhaps it might be a good idea to invoke the checkdb each time there is a db upgrade to clear out any errors
Nice that it’s working. The performance issue seems unlikely to be related, as the recheck is only about size metadata that’s stored. That’s just for visuals and does not influence the behaviour in general. Thus I do suspect a weird coincidence (I know, no such things as coincidences, but then again… xD ).
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
