On Tue, Aug 04, 2009 at 04:42:10PM -0700, David Rees wrote: > On Tue, Aug 4, 2009 at 4:18 PM, John > Robinson<john.robinson@xxxxxxxxxxxxxxxx> wrote: > > On 04/08/2009 23:21, David Rees wrote: > >> Near layout, 4 disks, 2 copies: > >> a b c d > >> 0 0 1 1 > >> 2 2 3 3 > >> 4 4 5 5 > >> 6 6 7 7 > >> > >> Far layout, 4 disks, 2 copies > >> a b c d > >> 0 1 2 3 > >> 4 5 6 7 > >> 7 0 1 2 > >> 3 4 5 6 > > > > But I don't think I'd want reads isolated to the first half of the disc. If > > I wanted a block read, and the drive which has its near copy is already > > busy, but the drive with the far copy is idle, I'd probably rather the read > > came from the far copy, than wait for the drive with the near copy to come > > free. > > > > For example, say I want block 0, and there's a write pending for block 3. I > > want block 0 from drive b now, not drive a later. > > In that case, it seems that it should be fastest to retrieve it from > the idle disk b, even if it has to go to the slower half of the disk. > After all, any write will take at least as long as the read will. You seem to not appreciate the elevator queue as I explained it in a previous message. Disks are not idle, they are always servicing their elevator queue. > > Or will I actually get more IOPS by waiting, if I'm doing a lot of small > > reads and writes? > > I doubt it - if you're doing a lot of small reads and writes, during > the writes the heads will be frequently seeking to the slow half of > the disk, anyway. Writes are only done when the caches are to be flushed, like every 30 secs or 5 secs or so. And the writes will be ordered by the elevator algorithm to minimize the seeks, very considerably. Given that the IO is random, in theory there should not be any difference on the ordered random queues of raid10,f2 and raid10,n2. > Of course, benchmarks would tell for sure. ;-) Sure! Best regards keld -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
