1.9.0: Time for Rescan increases dramatically on Windows

Support
1

I just updated to version 1.9.0. on two machines using Windows. “Rescan all” takes almost the same time on both machines:

  • 12 Minutes (version 1.9.0)
  • 70 Seconds (version 1.8.0).

Local State (Total) 138.431 files 21.523 directories ~52,6 GiB Processor machine 1: i5-3470 @ 3.20 GHz Processor machine 2: i7-3632QM @ 2.20 GHz

What information can I provide to help tracking down this issue?

BTW: On Linux the scan times are the same for 1.8.0 and 1.9.0: Approx 12 seconds on a Celeron G3900T @ 2.60 GHz. So this linux machine was always much faster than the Windows devices…

2 Likes
2

The scan process has changed in order to handle case insensitive systems. It does more work so it’s expected that it’s a bit slower. However my benchmarks showed roughly what you see on Linux, so I think it’s unexpected that it’s that much slower on Windows.

What kind of disks?

3

“Samsung SSD 850 EVO” on both Windows machines. No filesystem encryption.

Common hard disk on the Linux machine. Lukscrypt.

I tried it several time now:

Machine 1 stays at 12 Minutes.

Machine 2 takes approx. 4 Minutes now.

2 Likes
4

Apparently the scanning performance on Windows specifically is indeed pure sadness. We’ll fix it for the next release.

4 Likes
5

Is this justifying a 1.9.1 release? Scanning is really slow.

6

Currently I’m feeling “no”, as it’s not a functional problem and we’ve had it out in an RC for a while without any complaints.

But I plan to drop 1.10.0-rc later this week, which includes the fix, so those suffering mightily can hop on that train.

Or, worst case, set the caseSensitiveFS advanced folder option to disable the new checks. This brings back the 1.8.0 scanner, both performance wise and will-fuck-you-up-if-you-have-case-mismatches wise.

2 Likes
7

just to add another datapoint, rescan time on my windows systems (~220k files, 60GiB) went from ~5-10 minutes to hours (unknown how many, 4+; I gave up and set the caseSensitiveFS flag after I found this post as it was blocking any syncing from actually happening).

8

Hi,

in case someone feels the need for an immediate solution like me, I’ve made an unofficial build called “v1.9.1”. Please note it’s a build intended for my own use. It’s built on top of v1.9.0 + commit b628ec5054a9ac68d84ef7559017b9c217961f20 with the --no-upgrade switch. I cannot guarantee it’s “safe” for production use and just like to share it.

(Link removed, see calmh’s comment below. I think he’s right.)

Kind regards, Catfriend1

9

Please don’t do that. I know you mean well, but random patched Syncthings with what looks like a real official version number that doesn’t exist and upgrades disabled is something that makes me somewhat unhappy.

Do what you like on your own systems, of course, but once you start distributing binaries either do it properly and disclose the modifications and distribute the source, or don’t do it. Please.

We might release a 1.9.1 tomorrow to fix a critical issue and then anyone with your binary is in a mess.

If anyone is in an extreme hurry for a fixed binary, our nightly builds are that.

1 Like
10

Ok, sorry. I’ve edited my post.

1 Like
11
3 Likes
12

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