Messages in this thread | | | Date | Sun, 6 Jul 2008 16:44:16 -0400 | From | "Timothy Normand Miller" <> | Subject | Re: HELP: Getting unexpected fakeraid behavior. Fix? |
| |
On Sun, Jul 6, 2008 at 4:19 PM, Arjan van de Ven <arjan@infradead.org> wrote:
>> Since RAID1 is a mirrored configuration, it's possible to distribute >> reads across the drives, improving throughput and latency over a >> single drive on random reads. > > This is.. borderline true. Let me explain the caveats; > for a SINGLE THREADED workload, there is actually no difference. > Balancing long sequential reads over the 2 disks isn't such a good idea > for that case, since it just introduces seeks rather than keep up with > the streaming speed. > Balancing seeks; there might be some theoretical advantage because you > could, again in theory, do shorter seeks if you keep one head at the > inside and one the other disk head on the outside. In practice... a lot > of the seek time is rotational latency so it's not as big a deal as it > may sound; the moment you seek you pay a ton.
Ok, I see. This makes sense. It is a single thread. I did kindof expect that since the spatial locality of the metadata and files themselves (thousands of 2K byte files being read in a different order from which they were created) should not be very good, the kernel would round-robin (or probably something better) the requests (single blocks and sequential groups of blocks) between drives.
So, if I were to divide these reads across multiple threads, I would see requests to both drives? I'm wondering now if that would really help, although as far as I can tell, what I'm doing is dominated by seek time.
And the kernel pays attention to which thread caused a given request? What if you have two threads alternatively reading one file? (Which would obviously have to be serialized by locks.) Just curious. :)
> if your application is single threaded this isn't totally unexpected as > a result...
Oh, and one other question. I know the drives are AHCI capable, and when I read the drive flags, they report that it's enabled, and that the queue depth is 31. For the controller, the BIOS has three settings, IDE, AHCI, and RAID. In IDE mode, NCQ and other AHCI features are disabled. Unfortunately, the BIOS and manual for the motherboard do not state that AHCI features are enabled in RAID mode. Is there a way I can query to kernel to see if it's actually USING NCQ?
The reason I'm on about this is that the workloads I'm throwing at this computer are (sometimes) badly bottlenecked by the disks, so if I can get better throughput, that would help a lot.
Thank you for your help.
-- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project
| |