Now, whether the kernel actually merge them or not, I don't think we can tell from process monitor, can we? My impression is that process monitor intercepts library calls, not kernel calls or actual I/O calls.ĭo you feel confident that the fact that these operations appear as individual rows in process monitor is indicative of a problem? I then wait for all operations to complete. This should let the lower layer merge them, just like normal kernels do.
Which issues all reads (or writes) as overlapped (asynchronous) operations, in order, back-to-back. I've reverted back to 2.2.1 for the time being since this is my primary media server and having it freeze up is not an option.So, after having looked into this a bit, I'm pretty confident the vast majority of those reads (at least the ones whose offset are back-to-back) are part of my pwritev() emulation. I've done clean installs, upgrades, clean uninstalls and re-installs and nothing makes a difference. There is something seriously wrong with 3.0. Seeing as the disks in questions is an 8TB array with dual controllers (and at least 4 TB free at the moment) I doubt seriously it is the hardware-especially since the older version works fine. I tried 3.0, 254460 this morning and it locked up the system hard after less than 15 minutes of running with the exact same set of torrents, same hardware, same OS (win2003 server). I just ran 30 days under 2.2.1 and experienced no issues. Same torrents, same hardware, same settings under 2.2.1 and no problems.
Within 10 minutes of launching 3.0 the hardware interrupts (from proc explorer) skyrocket from an average of < 2 to over 30 when utorrent 3.0 runs, disk overloaded messages appear and the system becomes nearly unusable as CPU is pegged.
I get the disk overloaded problem constantly under 3.0. This problem has rendered version 3.0 useless for me.
0 kommentar(er)
