Feature idea: Suspend and Resume SR disk activity based on system disks utilization

[Jens Bornemann]

Hi Andrea,

I've noticed some time back a really nice feature in Windows 2012 dedupe service that would be a nice addition to SR: suspend disk activity when user or other services are also heavily accessing the disk.
I'd consider the role of SR to be a background activity, ensure raid is in sync and scrubbed.

In most cases we use nightly scheduled to avoid those cases, but I'd like not a bundle sync and scrub and ... at night and rather try to balance it through the day, like a heavy nightly job and heavy job at noon. Also, sometimes it cannot be controlled...

I try to find for Windows platform any signaling/event that might already exist.

Cheers,
Jens.

Update: I would imagine another process could monitor general disk activity and put the snapraid process in a suspend mode and resume it again, but don't really like that way ;-)

[Andrea Mazzoleni]

Hi Jens,

I'm not really convinced on this idea. It has too many unknown attached to it. Like how to detect when another program is starting some disk activity while SnapRAID is already running.

Ciao,
Andrea

[Jens Bornemann]

Hi Andrea,

I thought about it today again and tested today different I/O Priority behaviors.
I simply used the Process Hacker to play with different I/O priorities of two competing file copy processes on the same disk. Finding: it actually works pretty good, but only when one process it set to the lowest level ("Very Low"). Then that process gets so few I/O that the other has almost as much as if it would be the only one. But the "Very Low" is unfortunately not the solution, because if always set and even no other process is actually accessing that disk, the average "throughput" is approx. 3 times or so lower than on "Normal" level. Also, the "High" level doesn't really push the important process that noticeable up, as "Very Low" effectively does the down.

But I'm confident if disk I/O counters on the entire disk and on SR process would be captured, and sudden shifts between them (per some time unit) are identified, then SR could simply change its own I/O Priority to "Very Low" and reset it to "Normal" once disk I/Os normalize again.

Ok, that could be also set as easy from another "I/O Priority Manager" tool ;-) hmm... still don't like that idea, but probably such a tool exists already. Will check on that.
(Might evolve into a Process Hacker Plugin... Will post any finding/progress.)

Cheers,
Jens.