Syncthing 2.0: Migration running for 27 hours (and counting?)

I saw an upgrade was available to Syncthing 2.0 and started the process. It’s been running for 27 hours on two of the machines in my cluster and seems to be slowly making progress ever since.

I have a fairly large (huge?) amount of data (~40-50TB) in the 15 folders which are across the 3 machines in my Syncthing cluster.

I sorted through the logs and so far it seems to have completed 6 of those folders. But I’m beginning to have some questions:

  1. Is there anywhere I can read up on this migration to understand what’s taking so long?
  2. What exactly does the filesrate in the logs mean? Should I be worried that in the recent log entries filesrate has dropped into the single digits?
  3. What happens if the script gets interrupted?
  4. Is there anything that I can do to speed it up?

My Syncthing is running on my TrueNAS machine and obtained from its app catalog. The hardware is has a Xeon D-2123 CPU, 32 GB of RAM and 2 pools: a 4x1TB SATA SSD pool and a 7x20TB HDD pool. The Syncthing config and database are stored on the pool of SSDs. The folders being synched by Syncthing exist on both pools.

From what I’ve seen, there doesn’t seem to be any limitations with regards to hardware utilization, the CPU, RAM, and disk utilization for the machine all seem to be pretty normal

I primarily use Syncthing to make sure that my offsite NAS is up-to-date. I upgraded Syncthing on both machines at about the same time, each machine has been running upgrade for this whole time.

I have a third NAS which also is running Syncthing, but only 1 folder is set up on that machine. It’s upgrade compelted in moments and it’s currently functional.

If you have any suggestions or information you think might be helpful, I’d appreciate it!

Here’s the output of the upgrade. I trimmed out a bunch of the entries in the middle to fit under the character count:

2025-08-12 15:23:25.030129+00:002025-08-12 10:23:25 INF syncthing v2.0.0 "Hafnium Hornet" (go1.24.6 linux-amd64) docker@github.syncthing.net 2025-08-11 20:16:10 UTC [noupgrade, stnoupgrade] (log.pkg=main)
2025-08-12 15:23:25.043946+00:002025-08-12 10:23:25 INF Archiving a copy of old config file format (path=/var/syncthing/config/config.xml.v37 log.pkg=syncthing)
2025-08-12 15:23:26.066159+00:002025-08-12 10:23:26 INF Migrating old-style database to SQLite; this may take a while... (log.pkg=syncthing)
2025-08-12 15:23:26.116876+00:002025-08-12 10:23:26 INF Migrated folder (folder=3ttp5-tkee3 files=214 blocks=135 duration=0s filesrate=4376.51036900629 log.pkg=syncthing)
2025-08-12 15:23:33.488124+00:002025-08-12 10:23:33 INF Migrated folder (folder=4vcgo-nxwan files=35180 blocks=104716 duration=7s filesrate=4772.802248199005 log.pkg=syncthing)
2025-08-12 15:23:33.534216+00:002025-08-12 10:23:33 INF Migrated folder (folder=9v6qy-gqtfj files=25 blocks=3964 duration=0s filesrate=543.9960031525657 log.pkg=syncthing)
2025-08-12 15:23:43.862676+00:002025-08-12 10:23:43 INF Still migrating folder (folder=ayyji-rhtvt files=5000 blocks=822678 duration=10s filesrate=484.0984845507137 log.pkg=syncthing)
2025-08-12 15:23:54.006454+00:002025-08-12 10:23:54 INF Still migrating folder (folder=ayyji-rhtvt files=13000 blocks=1156198 duration=20s filesrate=635.0106536897486 log.pkg=syncthing)
2025-08-12 15:24:07.379134+00:002025-08-12 10:24:07 INF Still migrating folder (folder=ayyji-rhtvt files=18000 blocks=1702850 duration=33s filesrate=531.837751839849 log.pkg=syncthing)
2025-08-12 15:24:25.128154+00:002025-08-12 10:24:25 INF Still migrating folder (folder=ayyji-rhtvt files=19000 blocks=2471926 duration=51s filesrate=368.2603796761619 log.pkg=syncthing)
2025-08-12 15:24:28.329490+00:002025-08-12 10:24:28 INF Migrated folder (folder=ayyji-rhtvt files=19224 blocks=2592984 duration=54s filesrate=350.83411154301785 log.pkg=syncthing)
2025-08-12 15:24:28.469976+00:002025-08-12 10:24:28 INF Migrated folder (folder=b9ywy-vhuqk files=17 blocks=18516 duration=0s filesrate=121.14306923077706 log.pkg=syncthing)
2025-08-12 15:24:38.273770+00:002025-08-12 10:24:38 INF Migrated folder (folder=dmhay-pqhm7 files=50200 blocks=99904 duration=9s filesrate=5120.476166192009 log.pkg=syncthing)
2025-08-12 15:24:48.330847+00:002025-08-12 10:24:48 INF Still migrating folder (folder=fusoz-ccehv files=14000 blocks=366373 duration=10s filesrate=1392.0820286928658 log.pkg=syncthing)
2025-08-12 15:24:58.909208+00:002025-08-12 10:24:58 INF Still migrating folder (folder=fusoz-ccehv files=24000 blocks=947553 duration=20s filesrate=1163.065235447792 log.pkg=syncthing)
2025-08-12 15:25:09.183539+00:002025-08-12 10:25:09 INF Still migrating folder (folder=fusoz-ccehv files=32000 blocks=1444236 duration=30s filesrate=1035.2763938400385 log.pkg=syncthing)
2025-08-12 15:25:19.302876+00:002025-08-12 10:25:19 INF Still migrating folder (folder=fusoz-ccehv files=41000 blocks=1806104 duration=41s filesrate=999.2949466217274 log.pkg=syncthing)
2025-08-12 15:25:41.084658+00:002025-08-12 10:25:41 INF Still migrating folder (folder=fusoz-ccehv files=48000 blocks=2706551 duration=1m2s filesrate=764.2001431006927 log.pkg=syncthing)

...

2025-08-13 17:05:27.298007+00:002025-08-13 12:05:27 INF Still migrating folder (folder=fusoz-ccehv files=261000 blocks=131595590 duration=25h40m49s filesrate=2.823177448869106 log.pkg=syncthing)
2025-08-13 17:26:32.158077+00:002025-08-13 12:26:32 INF Still migrating folder (folder=fusoz-ccehv files=270000 blocks=132702239 duration=26h1m53s filesrate=2.881109905767438 log.pkg=syncthing)
2025-08-13 17:52:14.956941+00:002025-08-13 12:52:14 INF Still migrating folder (folder=fusoz-ccehv files=271000 blocks=134122598 duration=26h27m36s filesrate=2.8449447529937313 log.pkg=syncthing)
2025-08-13 18:21:18.168171+00:002025-08-13 13:21:18 INF Still migrating folder (folder=fusoz-ccehv files=272000 blocks=135575922 duration=26h56m39s filesrate=2.804126767252985 log.pkg=syncthing)
2025-08-13 18:48:12.423574+00:002025-08-13 13:48:12 INF Still migrating folder (folder=fusoz-ccehv files=273000 blocks=137002961 duration=27h23m34s filesrate=2.7683654175067383 log.pkg=syncthing)


1 Like

I can only say that with this amount of data, the migration process will likely take days (if not more).

I think the exact number of files isn’t that important, because this is about the number of blocks in the database, e.g. you can have a folder with a single 100 GB file, which will take longer time to migrate, and a folder with 100,000 very small files, which will migrate much faster.

The file rate is unfortunately precisely what you might think it is – migrated files per second at the current point in time. Inserts get slower as the database gets larger, because of index rewrites and whatnot, SQLite internals. Two and a half files per second is obviously abysmal and will take ages, assuming you have more than say 274000 files in that folder… I’m going to run a couple of benchmarks to see if this seems reasonable or not.

Is the database on SSD or spinning disks?

Darn, I hope I was guessing wrong!

The Syncthing database is on the 4x1TB SSD pool.

The folder it is currently working through has 435,463 files in it.

Yeah, the hundreds of millions of blocks is what is hurting you here primarily I think, because they go into the same database. That probably needs some sort of sharding to behave reasonably, which we don’t do.

Right now, manual sharding into smaller folders might be the only practical advice. (Or, obviously, sticking with v1 for the moment, unfortunate as that is.)

If the files are unevenly sized, it might be a little bit of a hump as well. I notice that in the beginning you have 2706551 blocks in 48000 files (avg 56 blocks per file) while in the last output it’s up to 137002961 blocks in 273000 files (avg 501 blocks per file). If it’s currently processing files with 1000 blocks each then that file rate of 2.8 is still something like 2800 database inserts per second which is maybe not great for your case but not molasses either. If some remaining files are smaller it could pick up speed.

1 Like

That makes sense! This particular folder would definitely will have files of different sizes in it. There’s quite a bunch of video footage from cameras that might explain the differences.

I uploaded the the entire log to pastebin. Do you think it’s worrisome at all that there’s a distinct downward trend in the filesrate?

From your description, it doesn’t sound like there would be much benefit to wiping everything out and starting over from scratch. Am I understanding that correctly?

There will be no benefit from starting over, for sure. There will always be a downward trend, because inserts get slower the more data there already is in the database (because items are ordered by primary key and pages need to be rewritten to make space, as I understand it, simplified). The question is if there can ever be an upwards trend again, and it’s at least possible if you have files of varying size.

2 Likes

I’m having a similar problem to that of briancmoses… I’m currently running TrueNAS Community version 25.04.2.1. Syncthing was updated earlier today to version 2.0 and has been in Deploying mode for about 12 hours. Where briancmoses is able to view several lines of his logs, I am only able to see the standard 2 lines…

2025-08-13 13:57:55.296541+00:002025-08-13 16:57:55 INF syncthing v2.0.0 “Hafnium Hornet” (go1.24.6 linux-amd64) docker@github.syncthing.net 2025-08-11 20:16:10 UTC [noupgrade, stnoupgrade] (log.pkg=main)

2025-08-13 13:57:55.918506+00:002025-08-13 16:57:55 INF Migrating old-style database to SQLite; this may take a while… (log.pkg=syncthing)

Once I was made aware that this is a migration, I then realized that it could take quite some time, due to my having a very large photo archive (I’m a retired photojournalist).

Nothing else has popped up in the logs. Is this normal or problematic? Should I be seeing some lines of progression?

I’m very much a newbie to this and any help would be greatly appreciated.

Thanks so much,

Kevin

This comment is probably more appropriate in the thread that you already started, @kunger .

From what you’ve shared, you’re having a completely different issue than what I’ve described here.

In my limited experience of upgrading 3 Syncthing instances you should have seen some more meaningful output about the migration’s progress by now.

Thanks!

Popped it in the tread that I already started. Let’s see how that works out!

Best,

Kevin

I’m facing the same problem, oddly on one of my servers only.

It’s synced with another server which got migrated to v2 in less than an hour.

I even tried removing all the databases, and reinstall syncthing and configure again, but the issue is the same and scanning takes too long.

62,122 files 24,678 directories ~13.8 TiB

My problem is it gets too slow after a couple of hours, it doesn’t happen on an identical server which this is synced with.

syncthing-log.txt (12.3 KB)

So the two servers have the same amount of synced data, but one takes ages to migrate and the other doesn’t? I have no explanation for that.

I just checked contents of two directories and there is a difference,

-rw-r--r-- 1 user user 601M Dec 15 2024 /path/to/file/filename.sync-conflict-20250815-060105-XXXXXXX.mp4

This file is only available on working server.

Although it has been created prior to creating this new folder months ago, I’m not sure if this could be related.

$ cat /path/to/.stfolder/syncthing-folder-1234567.txt # This directory is a Syncthing folder marker. # Do not delete.

folderID: aaaaa-bbbbb created: 2024-12-17T15:29:09+03:30

To add a (previously-reported) point of reference: for migrating a HDD-based NAS with about 140GB of data to v2:

[start] 2025/06/10 14:08:39 INFO: Migration complete, 8703987 files and 212964k blocks in 67h21m49s

1 Like

For the sake of sharing another data point, my second (of three) machine completed its Syncthing 2.0 database migration:

2025-08-15 02:47:54.997812+00:002025-08-14 21:47:54 INF Migration complete (files=1848207 blocks=258822 duration=59h24m45s log.pkg=syncthing)
2 Likes

Yeah… That’s like a sub-minute migration on my laptop, so something is certainly a bit off with how it runs here.

2 Likes

If a container upgrade to Syncthing 2.0 will fail, then it will be apparent in the docker log within five minutes of starting the database migration.

For example: ix-syncthing-syncthing-1.log.txt (9.2 KB)

In this example, the filesrate value decreased from 400 to 40 within ten minutes, and it will continue to approach zero until the expected runtime is months or years.

When this happened, iostat was reporting a disk utilization rate of 25% and vmstat was reporting a memory utilization rate of 50%, so Syncthing 2.0 should/does have enough system capacity to quickly finish the conversion.

I also tried setting sync=disabled according to an sqlite troubleshooting tutorial, but it had no effect.

Is there anything you can recommend that I try? I’m down to filesrate=1.4097565115211683 on the remaining machine.

I am perfectly happy to let it keep chugging along. But I’m a tiny bit worried about the remaining folders it hasn’t even attempted to migrate though. The folder it’s on is the second largest but I have an even larger folder that hasn’t even started yet.

I’m willing to be a guinea pig, though.

Is it just me, or do most of these reports all seem to have TrueNAS SCALE (or Community Edition) in common?

Three more troubleshooting points:

  • The syncthing:2.0.0 and syncthing:2.0.1 docker images both express the bug on TrueNAS SCALE 24.
  • The index conversion stall happens similarly on NVMe, SSD, and HDD storage pools.
  • And it happens on singular non-raid pools too.

Recreating indexes instead of converting indexes has a predictable bounded walltime, so that is my local upgrade solution.