Variable block size support on by default?

Hi together,

I’m using Syncthing for several months now and am quite happy with it. Only now, I learnt of variable block size support:

But the feature is apparently there for a year by now.

The documentation states that at some point this will be on by default, and at some further point in the future, it will even be always-on / the only mode of operation.

Since a year has passed, I wonder if the time has come to go to the next step? Let me know if I rather should ask that question as a GitHub issue for more devs to see.

It’s already on by default (for newly added folders).

Thanks! I was believing in the docs: https://docs.syncthing.net/advanced/folder-uselargeblocks.html which state it is not on by default yet, and it was also off on all my folders. Do you know in which version the default was changed?

The original change happened in v1.1.0 [see here: https://github.com/syncthing/syncthing/pull/5405], but due to a minor bug the default folder was not created with large blocks on until v1.1.1.

Relevant commits: https://github.com/syncthing/syncthing/commit/c75cfcfd06d09b5b2f7c242cfe86a7751d231587 and https://github.com/syncthing/syncthing/commit/50d8c43e7ccb9e14de66bac1545efaa1cdde6c38

Again, note that this does not affect any existing folders, only new installs and newly added folders. For folders that were created in an older version you need to manually turn it on on all devices. Alternatively remove and re-add the folder.

1 Like

Many thanks for the links! Then I’ll activate it manually for all folders on all my devices. Should I open an issue report about the documentation still lagging behind on the new default?

Or even better, a PR with an update. :slight_smile:

2 Likes

What about making it the default in general now, i.e. the usual notification bar explaining about it and asking whether it should be enabled on all existing folders?
We already had support requests of people that readded a folder (moving the root path, a new share, …). This now by default creates an undesirable state (old folders on remote stay disabled, new folders are enabled). Sure there will have to be an ugly part about “make sure folders on remote devices also set this option”, but I think that’s better than the silent discrepancies introduced via the new folder default, as the user is at least (or could/should be) aware of it.

2 Likes

I just did the PR. :slightly_smiling_face:

2 Likes

I think we had that as an alternative the last time as well (I wanted to do just that, IIRC) but that would mean potentially breaking people’s stuff as part of an automatic upgrade… It would have been great to have data on how many users are running with it on/off now, but we don’t.

I don’t remember. Anyway: Why break things? I was thinking about a UI notification prompting for a yes/no for enabling, i.e. nothing happens automatically.

Yeah I guess that’s not actually automatic. But saying “yes” puts you in an inconsistent state until you’ve done the same on all other devices. Which may or may not be under your control. So we’d have to be clear on that in the dialog, at least.

So there would be a temporarily disagreement what the size should be when scanning, but both sides should be able to download stuff, as there has been quite a few versions since?

That it should be enabled everywhere should definitely be mentioned. And as Audrius says, while it is inconsistent it shouldn’t cause major issues even long term (at worst conflicts, even though I still don’t understand why these happened, probably some hashing). Incidentally I just discovered that I forget to set the option on one of my folders on just one device, and there are frequent changes and I didn’t yet notice a problem. In any case having the user be aware of that through the notification seems preferable to the current state. Unless anyone wants to do it, I can propose a PR until Friday.

There not being a problem in the future scenario also means there is not a problem in the current situation. But sure, we can enable it with a notification.

2 Likes

I didn’t mean it as a counter-argument, just why I think the problems are minor enough that we don’t need something entirely different - the problems indeed apply to in both the new and old scenario. The main advantage of the new behaviour in my view is that the user is made aware of the change and the recommended default is on everywhere.

2 Likes