Something that catches my eye occasionally, more so tonight then previously, when I defrag, is Syncthing treating the moved files as modified?
In theory it shouldn’t however a defrag that’s been running has resulted in many jobs thinking something has changed on the RO side. Many of the remote devices are showing as items changed (could this be the 95% / x B differences that keeps cropping up recently on RO devices?).
For example, a pst file that’s 10 years old (along with around 280Gb of data) has decided to now redownload in a folder that I know was pretty much up to date. There is no reason why that file would redownload as it’s part of a deep archive that no one knows exists and absolutely isn’t hanging off an Outlook .
I checked the SO side in case something hit the folder, eg, a crypto virus, but all seems ok.
I have shutdown Syncthing to let the defrag finish and then will resume when done.
Thought it worthy of reporting (in general, not support)
The RO screenshot shows those blue arrows, the files seem to have been compressed. Could that - if true - cause a metadata change or is the Windows’ compressed attribute not relevant to Syncthing’s scanner?
Are you using the built-in defragmentation tool or a 3rd party solution? The former should not cause any issues for sure, but with the latter there is always a possibility that the software is doing some shenanigans while defragmenting the files.
W10’s own defragger often doesn’t kick in when needed, only when it decides. Whilst 3rd party defrags all use the windows API, there’s times where I want a little more control, usually to consolidate the free space.
I tend to only manually defrag when there is next to no activity, else Syncthing suffers with slow activity
I do find that Syncthing creates a lot of fragmentation so the scanning tends to suffer. I run large drives, 5 / 8 / 14Tb so I have to be on top of the optimization.
Just for the record, it does not happen “automagically”, but rather there is a scheduled task that runs only when idle, and only when there are mechanical HDDs present in the system. “Idle” in Windows 10 usually means a state after at least 4 minutes of inactivity or, in other words, lack of any user input (e.g. mouse, keyboard, stylus, etc.) and no video being played.
I personally disable the built-in task and do not bother defragmenting hard drives anymore, not because there is no benefit, but simply due to the fact that it takes way too much time. The only ones that I would still bother to do it are 10k or 15k rpm SAS drives.
I didn’t know about the block pull order, so have updated the config and will give that a go. im still defragging - 24 hours in and still at 31%!! it’s the Tb sized files that drag the scan speed down when they get fragmented.
I’ve heard others say this about W10s defragger but it’s not something that’s ever troubled me. I can see that with your very large HDDs the scheduled task might not be suitable.
Have you ever tried pausing Syncthing while defragging to see if the problem with moved files being treated as modified disappears? Or with such large drives would this put Syncthing out of action for an unacceptably long time?
It is all right . I just wanted to add some details regarding the defragmentation process’s run conditions. Also, just for completeness, Windows Vista and older will in fact defragment SSDs too, so there the automatic task should definitely be disabled (unless there are no SSDs in the system).