Restarted untrusted device and delta indexes out of reality

Hello,

I am happily using Syncthing between 2 computers at home (6TB, 1.3mio files). 13 folders, some send & receive, some send only, some receive only based on where source of data is. Second device is somewhat backup to master data on first device and vice versa. Everything workgs great!

With untrusted devices functionality I added third untrusted device off site, somewhere far away as “offsite receive only encrypted storage” in case of losing my two primary computers. For just part of files (3TiB)… This third device has very limited speed connection (like 1MiB/sec) so I am counting on very long times to transfer data there. Which is no problem, I can wait for it. Unfortunately, every restart of that third device is causing transfering 6GiB of index data! No delta-indexes used! … Is that normal behaviour? … I tried -reset-deltas on all machines, still there are messages on third device claiming both home computers “is delta index compatible, but seems out of sync with reality” … Why is that?! … And what can I do to make it work? Sending 6GiB each time on that slow line is propably too long to actualy sync something (which is not, because no files changed at home computers for most of the time)

Is there problem have untrusted device linked with two trusted, which are linked too?

Looks like new added folder and shared on all devices have no this behaviour (is not listed as out of reality index). Are previous folder somewhat not migrated/prepared for this function?

[edit] - oh, sending again and again this amount of data is each time I pause/unpause folders on the any home computer :open_mouth: … can’t be right

Not sure if it’s supposed to happen, but I have the same situation here, also on a slow connection.

To tell the truth, this makes Receive Encrypted folders somewhat unusable if your connection has limited bandwidth, and especially if it’s unstable, because every reconnection will trigger a new index exchange, which then often gets interrupted in the middle when the connection drops, and it has to restart again when the two devices reconnect, ending in some kind of an endless index exchange loop.

1 Like

That’s definitely not the intended behavior.

That’s what I thought, but I couldn’t do any more testing then, so I just left it like that. One thing to note is that the issue may go unnoticed if you do your testing locally, e.g. using multiple instances on the same computer, where there are no bandwidth constraints. It should be possible to reproduce by setting artificial bandwidth limits inside Syncthing though. I’m going to test this shortly and open an issue if the behaviour persists.

Interesting clue:

newly added folder (exact same configuration as historic folder) is not logging out of reality index:

A (send only) <==> B (receive only)

A (send only) ==> C (receive encrypted)

B (receive only) ==> C (receive encrypted)

seems ok … .

Same configuration (maybe A or B or C was in history linked to D (not exist anymore)), but at existing folder (from like prehistory) not using deltaindexes

I would rather not re-add folders. One of my home device is Raspberry. 6TB of data is hashing for weeks :smiley:

Can you think of an workaround around this? Without rehashing all data again? … What would cause fresh folder is working as intended while old one is not (same parameters on all devices)?

I have no idea what the problem is so I’m not sure what workaround might apply. You could post full logs for a couple of connection attempts and it might possibly shed some light.

I do see this issue in my test setup but didn’t figure out why it happened yesterday before bedtime - I had another look now :slight_smile:

The problem is the sequence number, which gets lost between untrusted and trusted devices: https://github.com/syncthing/syncthing/issues/7994

2 Likes

I just wanted to say thank you! What was unusable before is working perfectly fine now, even with the limited bandwidth I’ve got here :slightly_smiling_face:.

1 Like

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