On Tue, Nov 3, 2009 at 9:31 AM, Michael Evans <mjevans1983@xxxxxxxxx> wrote: > Is it possible the data-set you are testing with is too small? Modern > drives have caches of around 32MB, your test might only be executing > within the drive's caches. Cache is disabled on the drives, and disabled on the system by using O_DIRECT on the benchmark. I am seeing proper behavior using synchronous writes, but that slows down performance too much. Chris > > On Tue, Nov 3, 2009 at 4:37 AM, Sujit K M <sjt.kar@xxxxxxxxx> wrote: >> This I think is an reported bug. >> >> On Mon, Nov 2, 2009 at 11:58 PM, Chris Worley <worleys@xxxxxxxxx> wrote: >>> I expect RAID1 write performance to be, at best, the performance of >>> the slowest drive. >>> >>> I'm seeing twice the performance, as if it were a RAID0. The read >>> performance is 2x also, which is what I would expect. >>> >>> I'm using the incantation: >>> >>> mdadm --create /dev/md0 --chunk=256 --level=1 --assume-clean >>> --raid-devices=2 /dev/sd[bc] >>> >>> I use "assume clean" on the fresh create, as there is no reason to >>> sync the new drives. >>> >>> My "fio" test uses O_DIRECT with 64 threads, each with a queue depth >>> of 64, running for 10 minutes. All caching is disabled, and the NOOP >>> scheduler is being used. I run this test all the time, and can't >>> imagine why it's getting such repeatably good write performance. >>> >>> Any ideas? >>> >>> Thanks, >>> >>> Chris >>> -- >>> 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 >>> >> >> >> >> -- >> -- Sujit K M >> >> blog(http://kmsujit.blogspot.com/) >> -- >> 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 >> > -- 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