However when it does its regular check (configurable frequency, every 5 minutes by default) via storectrl.dll, it attempts low-level access to no fewer than 256 physical disks:
- StoreCtrlLog.png (144.36 KiB) Viewed 288 times
StoreCtrl.dll scanning 256 physical disk drives
-
InquiringMind
- Posts: 23
- Joined: 2024.10.20. 22:03
StoreCtrl.dll scanning 256 physical disk drives
As part of my security setup I run System Safety Monitor (http://web.archive.org/web/20080919100508/http://www.syssafety.com/default.html), which controls what applications can run and what they can do. One of the actions that can be controlled is low-level disk access which should only legitimately be needed by disk utilities like HDSentinel.
However when it does its regular check (configurable frequency, every 5 minutes by default) via storectrl.dll, it attempts low-level access to no fewer than 256 physical disks: Now I accept the frequency is configurable and there appears to be little impact on CPU utilisation, but this still seems quite excessive. It surely would make sense to only attempt access to disks physically present - and if anyone out there actually has 256 disks connected, maybe they should be nudged onto the Enterprise version?
However when it does its regular check (configurable frequency, every 5 minutes by default) via storectrl.dll, it attempts low-level access to no fewer than 256 physical disks: Now I accept the frequency is configurable and there appears to be little impact on CPU utilisation, but this still seems quite excessive. It surely would make sense to only attempt access to disks physically present - and if anyone out there actually has 256 disks connected, maybe they should be nudged onto the Enterprise version?
-
InquiringMind
- Posts: 23
- Joined: 2024.10.20. 22:03
Re: StoreCtrl.dll scanning 256 physical disk drives
Hmm...looks like there is some variation here. Did a check on another system (with only one disk) and (a) the scanning is done by HDSentinel.exe and (b) it is limited to a mere 99 drives...
- HDSentinelLog.png (103.82 KiB) Viewed 278 times
-
hdsentinel
- Site Admin
- Posts: 3115
- Joined: 2008.07.27. 17:00
- Location: Hungary
- Contact:
Re: StoreCtrl.dll scanning 256 physical disk drives
Yes, what you see is completely normal and expected behaviour.
> appears to be little impact on CPU utilisation,
There is absolutely NO impact on CPU utilisation of course - otherwise things would be different
Just for fun, a quick test made to scan *really* excessive number of disk drives, just to measure the total time required.
I used a very-very old dev system (I7-3770K CPU, Windows XP). The results were:
1) scanning 10000000 (ten million) drives took 28922 ms
2) scanning 100000 drives took 281 ms
3) scanning 10000 drives took 31 ms
4) scanning 1000 drives took 0 ms
so less is also 0 time...
> It surely would make sense to only attempt access to disks physically present
This is exactly what you see: the software checks which disks physically present (by attempting to access them). Nothing more and nothing else.
You may feel "oh, but it should stop on first drive which is not present", but that would be a false solution.
Please note that while the numbering is generally linear, if we does not see a drive (let's drive 2) we can't assume that there is no drive 3, drive 4 and so (as it is possible that previous disk(s) removed). This is why the scanning.
I remember 10+ years ago when it was fewer - and then I received "bug report" that Hard Disk Sentinel could not see more than 200+ drives.
This is why it is extended - and (if required, as it depends on different factors) then yes, relatively high number of drives scanned - which is not only completely normal and expected but completely safe and uses absolutely no resources.
> maybe they should be nudged onto the Enterprise version?
Absolutely NOT. The Enterprise Server itself does not scan/detect/access disk drives at all, "just" collects/shows the status from the clients - the Hard Disk Sentinel Professional which is detecting the status and expected to detect ALL possible drives.
> appears to be little impact on CPU utilisation,
There is absolutely NO impact on CPU utilisation of course - otherwise things would be different
Just for fun, a quick test made to scan *really* excessive number of disk drives, just to measure the total time required.
I used a very-very old dev system (I7-3770K CPU, Windows XP). The results were:
1) scanning 10000000 (ten million) drives took 28922 ms
2) scanning 100000 drives took 281 ms
3) scanning 10000 drives took 31 ms
4) scanning 1000 drives took 0 ms
so less is also 0 time...
> It surely would make sense to only attempt access to disks physically present
This is exactly what you see: the software checks which disks physically present (by attempting to access them). Nothing more and nothing else.
You may feel "oh, but it should stop on first drive which is not present", but that would be a false solution.
Please note that while the numbering is generally linear, if we does not see a drive (let's drive 2) we can't assume that there is no drive 3, drive 4 and so (as it is possible that previous disk(s) removed). This is why the scanning.
I remember 10+ years ago when it was fewer - and then I received "bug report" that Hard Disk Sentinel could not see more than 200+ drives.
This is why it is extended - and (if required, as it depends on different factors) then yes, relatively high number of drives scanned - which is not only completely normal and expected but completely safe and uses absolutely no resources.
> maybe they should be nudged onto the Enterprise version?
Absolutely NOT. The Enterprise Server itself does not scan/detect/access disk drives at all, "just" collects/shows the status from the clients - the Hard Disk Sentinel Professional which is detecting the status and expected to detect ALL possible drives.