Messages in this thread | | | From | Justin Cormack <> | Subject | Re: raid1 performance | Date | Wed, 1 May 2002 18:16:22 +0100 (BST) |
| |
> Lemme see if I am getting closer. > > When reading the disk there will be head seeks necessary. When there > are two disks, each with its own complete copy of all the data, there > is no reason to keep the two disks' heads in the same place. If their > heads are in different places, a read can be issued to the disk whose > heads are closer to the desired location.
yes. Look at raid1.c: the code is quite clear. Older versions didnt.
> This then brings up two more questions: > > 1. Does the OS even know where the heads are in a modern IDE disk?
Not really. But there is probably a vague correspondence. Especially if you havent remapped any bad sectors.
> 2. Is "closer" any more finely grained than a binary > positioned/not-positioned?
I think so. You can see different performance regions on disks (ie they are faster on the outside for example). You could of course write a program to test seek times from different areas and build up a real locality map. It might not be worth it though.
> And I guess another question: How much does RAID 1 help and under what > kinds of usage?
the latency is noticeably less in some cases, as the seeks should be smaller on average. I have found this useful sometimes.
Justin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |