Hi there, thanks for the response. I spent a lot of time the last couple days working on this and have some additional information that I'll try to weave in to the answers to your questions.
- When the issue first occurred, I did attempt to make a standard file transfer; that's in fact where I got the error message from my first screenshot. The OS thought it was legitimately full.
Since my initial post, I managed to discover a cause/solution for the 31% issue. It seems that the metadata cache surrounding the storage pool was somehow becoming corrupt, incomplete, what-have-you at that point without Windows ever recognizing that fact (must be a bug somewhere since it was immediately replicable). 'Update-StorageProviderCache' through Powershell solved that problem and I'm currently at ~40% utilization without recurrence. Chalking that up to an OS level issue w/ Storage Spaces and unrelated to the I/O errors at this point.
Despite being new the health of the drives was the first thing I checked, they are fine. As to the striping itself, I haven't seen any indications that there's a problem with data consistency.
-
The log entries from qbittorrent are fairly meaningless app-level statements but this is the general form of message from the Windows app log:
Warning, Event 153, Disk
"The IO operation at logical block address [block address] for Disk [#] (PDO name: \Device\00000[xxx]) was retried."
The frequency was the alarming nature (easily 50+ per second):
I use the word 'was' because that has since decreased drastically. First, yes the array was connected directly to the rear I/O; again, 'was' because upon further investigation I've come to notice that the I/O shield itself is slightly too big for the case opening it's covering, making it bow outwards as it settles. I think this was causing a bad connection on the motherboard end. I moved it to the front USB and saw a vast decrease in the frequency of I/O warnings.
But not a total elimination. Over the ten hours I waited since doing that, I logged another forty events but now they're infrequent enough to see that they're occurring in bursts:
My next culprit at the OS level was indexing and I've since shut it off on that 'drive'. In the three hours since that's happened, I haven't seen any more log entries but the jury's still out if it's actually fixed or not.
Event 153 comes from a storport miniport driver that I'm guessing is associated with how Storage Spaces is dealing with the disk I/O. So basically everything is pointing back towards the OS or possibly motherboard. The motherboard has a slight revision available (2.2a -> 2.3) that I have not flashed yet, it will be my next move if shutting off indexing doesn't work. I don't think I see any newer USB drivers for this board but if I flash the BIOS I'm going to verify all drivers at that time as well.
Thanks