Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Monday 26 January 2009 11:42:38 Florian Haas wrote: > On 01/26/2009 12:28 PM, Mark Watts wrote: > > On Friday 23 January 2009 18:13:55 Florian Haas wrote: > >> Mark, > >> > >> On 01/23/2009 05:01 PM, Mark Watts wrote: > >>> The following test was used to obtain a write average: > >>> # for loop in `seq 1 10`; do echo "Writing to /empty, loop $loop"; dd > >>> if=/dev/zero of=/empty bs=$(( 1024 * 1024 * 1024 )) count=4; done > >> > >> You're not writing to your disk, but to your page/buffer cache. Add > >> "oflag=direct". > > > > Ok. We've realised that we don't have the controller batteries either, so > > we're going to get some and re-test. > > If that is the case, it may well be that your controller is disabling > its write cache unless a battery is present (all sane controllers ought > to have that behaviour). That would mean you are writing in > write-through mode all along. So assuming that with "oflag=direct" your > write throughput is way less than you expect, that may be a possible > reason. Well, checking the raid config with the HP CLI utility, its saying that the controller cache is providing 100%Read / 0%Write accelleration, so this will probably improve with a battery. Looks like its disabled the caches on the drives too. I'm still mildy confused why (without oflag=direct) the DRBD volume is so much slower than the plain LVM volume. Is this because we're using Protocol C? > > Yep, GigE here. Having said that, if everything else is capable/tuned of > > going faster then we should be hitting 100M almost all the time, right? > > For direct streaming writes, yes. 100 to 105MB/s should be nothing out > of the ordinary. OK. The actual app is a mostly-write database (PostgreSQL) so we probably won't be seeing sequential writes unless we're lucky. Mark. -- Mark Watts BSc RHCE MBCS Senior Systems Engineer QinetiQ Applied Technologies GPG Key: http://www.linux-corner.info/mwatts.gpg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20090126/e11f6a9b/attachment.pgp>