I have external backup disks (HDDs) with several logical drives (X, Y, Z).
Even when I set threads to lowest value (1 for each of them) 3 scan run at one time.
This makes the read head of the HDD jump back/forth between the 3 logical drives.
Is there an option somwhere to completly disable multiple scanning threads.
Making it scan sequaltial instead (first x, then y, then Z).
Single scan thread (not multiple threads)
- Posts: 27
- Joined: 6 Jul 2018
-
- Site Admin
- Posts: 7523
- Joined: 9 Dec 2007
Folder scanning is inherently random-access. Even with a single thread the HDD read head would jump between file locations which are all scattered over the surface.¹
1) Exception: "very small files": https://learn.microsoft.com/en-us/archive/blogs/askcore/the-four-stages-of-ntfs-file-growth
1) Exception: "very small files": https://learn.microsoft.com/en-us/archive/blogs/askcore/the-four-stages-of-ntfs-file-growth
- Posts: 4908
- Joined: 11 Jun 2019
Yep, the only way to stop that is to format the drive(s) and re-copy all of the data to them so it's one contiguous set of blocks. Even then, there's going to be firmware and hardware choices that end up moving data around to seemingly random locations
- Posts: 27
- Joined: 6 Jul 2018
It does really matter if you do it in one job (3 tasks running at once) or one at at time.
I tried this to see if it matters...
One job with 3 scans:
D: -> X:,
S: -> Y:,
W: -> Z:
Takes over 4 minutes to scan (3 threads at at time)
3 separate jobs:
D: -> X: takes 15 sec
S: -> Y: takes 40 sec
W: -> Z: takes 1 minute
So it would really speed up things with a option to scan each sequaltially
I tried this to see if it matters...
One job with 3 scans:
D: -> X:,
S: -> Y:,
W: -> Z:
Takes over 4 minutes to scan (3 threads at at time)
3 separate jobs:
D: -> X: takes 15 sec
S: -> Y: takes 40 sec
W: -> Z: takes 1 minute
So it would really speed up things with a option to scan each sequaltially
-
- Site Admin
- Posts: 7523
- Joined: 9 Dec 2007
@LarsErikOsterud:
You have three partitions on one physical disk, this means one is placed in the innermost ring, one in the middle and one in the outer ring. When scanning a single partition, the HDD seek header still moves in a random-access pattern, but with a limited amplitude, while when scanning all three partitions at the same time, the amplitude becomes the full disk radius. This explains why parallel scanning of all three partitions is slower than sequential processing.
The question is, is this worth an extra option for FFS? Probably not, as the usecase of partitioning a spinning disk drive is rather niche at this point in time.
You have three partitions on one physical disk, this means one is placed in the innermost ring, one in the middle and one in the outer ring. When scanning a single partition, the HDD seek header still moves in a random-access pattern, but with a limited amplitude, while when scanning all three partitions at the same time, the amplitude becomes the full disk radius. This explains why parallel scanning of all three partitions is slower than sequential processing.
The question is, is this worth an extra option for FFS? Probably not, as the usecase of partitioning a spinning disk drive is rather niche at this point in time.
- Posts: 1222
- Joined: 8 May 2006
Just saying...
2 min. vs. 4 min.
What if it were 20 min. vs. 40 min.?
Or 200 min. vs. 400 min.?
Other softwares allow designating/setting volumes, groups of volumes, as "single-thread", kind of thing.
b3sum has poor performance for large files on spinning disks, when multi-threading is enabled
https://github.com/BLAKE3-team/BLAKE3/issues/31
And I noticed an oddity with multithreading enabled in CHK (hash program) [though don't recall just what the issue was, offhand?].
https://compressme.net/
> a spinning disk drive is rather niche at this point in time
I might argue that ;=).
2 min. vs. 4 min.
What if it were 20 min. vs. 40 min.?
Or 200 min. vs. 400 min.?
Other softwares allow designating/setting volumes, groups of volumes, as "single-thread", kind of thing.
b3sum has poor performance for large files on spinning disks, when multi-threading is enabled
https://github.com/BLAKE3-team/BLAKE3/issues/31
And I noticed an oddity with multithreading enabled in CHK (hash program) [though don't recall just what the issue was, offhand?].
https://compressme.net/
> a spinning disk drive is rather niche at this point in time
I might argue that ;=).
- Posts: 4908
- Joined: 11 Jun 2019
partitioning is the important part of that. Zenju is right, partitioning a single physical disk into multiple volumes has gone the wayside> a spinning disk drive is rather niche at this point in time
I might argue that ;=). therube, 16 Jul 2026, 15:46
-
- Posts: 2978
- Joined: 22 Aug 2012
> it would really speed up things with a option to scan each sequaltially
That option is already available via the "Run a command" option, at the bottom of the Synchronization Settings (F8).
To your D: -> X: sync configuration, add a command that runs your S: -> Y: sync
and to your S: -> Y: sync configuration, add a command that runs your W: -> Z: sync.
Then run your D: -> X: sync.
When your D: -> X: sync ends, it will start your S: -> Y: sync.
When your S: -> Y: sync ends, it will start your W: -> Z: sync.
Make sure to save your at least your S: -> Y: and W: -> Z: sync configurations are saved as *.ffs_batch sync configurations, so those can run within requiring user interaction.
That option is already available via the "Run a command" option, at the bottom of the Synchronization Settings (F8).
To your D: -> X: sync configuration, add a command that runs your S: -> Y: sync
and to your S: -> Y: sync configuration, add a command that runs your W: -> Z: sync.
Then run your D: -> X: sync.
When your D: -> X: sync ends, it will start your S: -> Y: sync.
When your S: -> Y: sync ends, it will start your W: -> Z: sync.
Make sure to save your at least your S: -> Y: and W: -> Z: sync configurations are saved as *.ffs_batch sync configurations, so those can run within requiring user interaction.
