New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrectly out of sync, sequence number oddness. #5340

Closed
calmh opened this Issue Nov 29, 2018 · 2 comments

Comments

Projects
None yet
3 participants
@calmh
Copy link
Member

calmh commented Nov 29, 2018

It seems there might be an occasional issue with the index sending. I noticed this in my home setup. Two devices, "kvin" and "pseudo"; kvin thinks pseudo is out of sync missing one file, pseudo thinks it has everything, but the file is missing.

kvin side:

screen shot 2018-11-29 at 09 15 05

screen shot 2018-11-29 at 09 15 13

(note 2702 files locally, pseudo missing one pdf)

pseudo side:

screen shot 2018-11-29 at 09 15 20

(2701 files locally)

Checking the file via rest shows it present on kvin but not pseudo, which matches the above:

jb@kvin:~ $ curl ... 'http://localhost:8384/rest/db/file?folder=documents&file=Kastelo/Ekonomi/2018+Bokföring/INV04871726_A00552008_11252018.pdf'
{
  "availability": null,
  "global": {
    "deleted": false,
    "ignored": false,
    "invalid": false,
    "localFlags": 0,
    "modified": "2018-11-26T07:03:54+01:00",
    "modifiedBy": "SYNO4VL",
    "mustRescan": false,
    "name": "Kastelo/Ekonomi/2018 Bokföring/INV04871726_A00552008_11252018.pdf",
    "noPermissions": false,
    "numBlocks": 1,
    "permissions": "0644",
    "sequence": 902,
    "size": 71947,
    "type": 0,
    "version": [
      "SYNO4VL:1"
    ]
  },
  "local": {
    "deleted": false,
    "ignored": false,
    "invalid": false,
    "localFlags": 0,
    "modified": "2018-11-26T07:03:54+01:00",
    "modifiedBy": "SYNO4VL",
    "mustRescan": false,
    "name": "Kastelo/Ekonomi/2018 Bokföring/INV04871726_A00552008_11252018.pdf",
    "noPermissions": false,
    "numBlocks": 1,
    "permissions": "0644",
    "sequence": 902,
    "size": 71947,
    "type": 0,
    "version": [
      "SYNO4VL:1"
    ]
  }
}

$ curl ... 'https://pseudo.int.nym.se:8384/rest/db/file?folder=documents&file=Kastelo/Ekonomi/2018+Bokföring/INV04871726_A00552008_11252018.pdf'
No such object in the index

The sequence number 902 is suspiciously low for this folder though; it's been around for a long time. Spot checking a couple of other files doesn't reveal anything conclusive though. One from Nov 14 (two weeks ago) has sequence 850 while another from Now 27 (one day after the affected one above) has sequence 49569. The latter seems more reasonable, and I'm not sure what would cause the large amount of updates between the 26th and 27th otherwise. (I mean, there are 2700 files in the folder, and they only change very occasionally.) This file is very recent, and a sequence < 2700 should be impossible.

Restarting kvin with -reset-deltas resolved.

@mietzen

This comment has been minimized.

Copy link

mietzen commented Dec 26, 2018

I wanted to open up an Issue and found this ticket, I think I might have the same Problem.
Home Server (send only) says Backup (receive only) is out of sync Backup says everythin is fine:

untitled

untitled2

Home-Server and Backup Server are both running on a Synology NAS. The files claimed to be out of sync are present on both NAS systems and haven't be changed.

@calmh If you have a fix for this I'm happy to test it on my system.

@vortigont

This comment has been minimized.

Copy link

vortigont commented Jan 4, 2019

Got the same issue. One of the peers report that some of the "remote devices" is not in full sync while there is nothing to sync actually, all files are in place with checksums match and all folders are reported in full-sync too.

imsodin added a commit to imsodin/syncthing that referenced this issue Jan 9, 2019

lib/db: Do all update operations on a single item at once (ref syncth…
…ing#5340)

To do so the BlockMap struct has been removed. It behaves like any other prefixed
part of the database, but was not integrated in the recent keyer refactor. Now
the database is only flushed when files are in a consistent state.

imsodin added a commit to imsodin/syncthing that referenced this issue Jan 9, 2019

lib/db: Do all update operations on a single item at once (ref syncth…
…ing#5340)

To do so the BlockMap struct has been removed. It behaves like any other prefixed
part of the database, but was not integrated in the recent keyer refactor. Now
the database is only flushed when files are in a consistent state.

imsodin added a commit to imsodin/syncthing that referenced this issue Jan 11, 2019

lib/db: Do all update operations on a single item at once (ref syncth…
…ing#5340)

To do so the BlockMap struct has been removed. It behaves like any other prefixed
part of the database, but was not integrated in the recent keyer refactor. Now
the database is only flushed when files are in a consistent state.

imsodin added a commit to imsodin/syncthing that referenced this issue Jan 13, 2019

lib/db: Do all update operations on a single item at once (ref syncth…
…ing#5340)

To do so the BlockMap struct has been removed. It behaves like any other prefixed
part of the database, but was not integrated in the recent keyer refactor. Now
the database is only flushed when files are in a consistent state.

imsodin added a commit to imsodin/syncthing that referenced this issue Jan 14, 2019

lib/db: Do all update operations on a single item at once (ref syncth…
…ing#5340)

To do so the BlockMap struct has been removed. It behaves like any other prefixed
part of the database, but was not integrated in the recent keyer refactor. Now
the database is only flushed when files are in a consistent state.

calmh added a commit to calmh/syncthing that referenced this issue Jan 18, 2019

lib/db: Fix iterating sequence index (fixes syncthing#5340)
There was a problem in iterating the sequence index that could result
in missing updates. The issue is that while the index was (correctly)
iterated in a snapshot, the actual file infos were read dirty outside of
the snapshot. This fixes this by doing the reads inside the snapshot,
and also updates a couple of other places that did the same thing more
or less harmfully (I didn't investigate).

To avoid similar issues in the future I did some renaming of the
getFile* methods - the ones in a transaction are just getFile, while the
ones directly on the database are variants of getFileDirty ot highlight
what's going on.

calmh added a commit to calmh/syncthing that referenced this issue Jan 18, 2019

lib/db: Fix iterating sequence index (fixes syncthing#5340)
There was a problem in iterating the sequence index that could result
in missing updates. The issue is that while the index was (correctly)
iterated in a snapshot, the actual file infos were read dirty outside of
the snapshot. This fixes this by doing the reads inside the snapshot,
and also updates a couple of other places that did the same thing more
or less harmfully (I didn't investigate).

To avoid similar issues in the future I did some renaming of the
getFile* methods - the ones in a transaction are just getFile, while the
ones directly on the database are variants of getFileDirty ot highlight
what's going on.

calmh added a commit to calmh/syncthing that referenced this issue Jan 18, 2019

lib/db: Fix iterating sequence index (fixes syncthing#5340)
There was a problem in iterating the sequence index that could result
in missing updates. The issue is that while the index was (correctly)
iterated in a snapshot, the actual file infos were read dirty outside of
the snapshot. This fixes this by doing the reads inside the snapshot,
and also updates a couple of other places that did the same thing more
or less harmfully (I didn't investigate).

To avoid similar issues in the future I did some renaming of the
getFile* methods - the ones in a transaction are just getFile, while the
ones directly on the database are variants of getFileDirty to highlight
what's going on.

@calmh calmh closed this in 1e69997 Jan 18, 2019

@calmh calmh added this to the v1.0.1 milestone Jan 18, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment