FFS performance and 'disablelastaccess' setting in Windows 10

[officeboy]

To clarify the comments on this on 16 October:

Windows 10, by default, records the date/time of every access to a file in each file timestamps field.
If FFS has to scan 10s of thousands of files for a sync operation, there is a significant overhead to recording the access times, which appears to be cached for asynchronous processing after FFS is done. During the processing of the queue, FFS performance on any subsequent sync operation can be greatly retarded, and an external drive handle may be kept open until the write job is finished.

The name of the setting is confusing.
The default value is 2, meaning that 'disablelastaccess' is not enabled, meaning that last access recording is *enabled*.
To disable last access recording, you use '1' or '3' to enable 'disabling' last access recording.

The setting is described here:
https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/fsutil-behavior

The easy way to set the value is to use fsutil. The setting you want is '1':

fsutil behavior set disablelastaccess 1

The potential impact on FFS performance is *big*.

[xCSxXenon]

Do you know any repercussions by enabling this?

[officeboy]

Have been working for 3 weeks with last access timestamping disabled, without any issues. I guess it might matter in a setting where access to files is monitored for security or forensic reasons. For me changing the setting rescued FFS on Windows 10, restoring the rapid scans and instant USB drive release I was used to on 32 bit Windows 7.

[gvp9000]

I set it to 1 and after a restart I have the same slow comparison after approx. 50.000 files.
Does the size of the sync.ffs_db has anything to do with it ?
Can I increase the size of sync.ffs_db ?