<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.6001.18063" name=GENERATOR></HEAD>
<BODY>
<DIV align=left><SPAN class=450575621-20062008><FONT face=Arial color=#0000ff size=2>The recommended practice for critical servers is to disable
the write cache on the hard drives, use a good raid controller with a good sized
cache and battery backup unit.</FONT></SPAN></DIV>
<DIV align=left><SPAN class=450575621-20062008><FONT face=Arial color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV align=left><SPAN class=450575621-20062008><FONT face=Arial color=#0000ff size=2>Hard disks these days have lots of cache (32MB in some
cases), so in the event of a poweroff you stand to lose a lot of data. Some raid
cards have the RAM and battery on a module so in the event of raid controller
failure, you can take the data held in RAM and transport to a new
controller.</FONT></SPAN></DIV>
<DIV align=left><SPAN class=450575621-20062008><FONT face=Arial color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV align=left><SPAN class=450575621-20062008><FONT face=Arial color=#0000ff size=2>In the tests that I did, comparing the "flushes" options,
the performance was so incredibly different that I would go so far as to be a
bit cheeky and say that something is broken in the code. Or perhaps
over-sensitive, you choose the terms to use but the bottom line is that adding
those parameters completely transforms the throughput.</FONT></SPAN></DIV>
<DIV align=left><SPAN class=450575621-20062008><FONT face=Arial color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV align=left><SPAN class=450575621-20062008><FONT face=Arial color=#0000ff size=2>As an aside, we found no difference in our limited
performance tests with internal or external metadata. </FONT></SPAN></DIV>
<DIV align=left><SPAN class=450575621-20062008><FONT face=Arial color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV align=left><SPAN class=450575621-20062008><FONT face=Arial color=#0000ff size=2>Lee.</FONT></SPAN></DIV><BR>
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader align=left>
<HR>
<FONT face=Tahoma size=2><B>From:</B> drbd-user-bounces@lists.linbit.com
[mailto:drbd-user-bounces@lists.linbit.com] <B>On Behalf Of </B>Marcelo
Azevedo<BR><B>Sent:</B> 20 June 2008 22:37<BR><B>To:</B>
drbd-user@lists.linbit.com<BR><B>Subject:</B> Re: [DRBD-user] Significant
performance improvement!<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV>Dear Lars,</DIV>
<DIV> </DIV>
<DIV>The backend devices are on a <A class=l href="http://www-132.ibm.com/webapp/wcs/stores/servlet/ProductDisplay?productId=4611686018425211442&storeId=1&langId=-1&catalogId=-840"><FONT color=#0000cc>IBM <B>ServeRAID</B>-<B>8k</B> SAS <B>Controller</B>
</FONT></A></DIV>
<DIV>with 256MB battery backed write cache</DIV>
<DIV> </DIV>
<DIV>you are saying i should not have seen a performence hit with a </DIV>
<DIV>battery backed write cache?</DIV>
<DIV> </DIV>
<DIV>i now tried with internal metada , options :</DIV>
<DIV> no-disk-flushes;<BR>
no-md-flushes;</DIV>
<DIV><BR> and it now works almost to naive speed.</DIV>
<DIV> </DIV>
<DIV>results are similar as when i had the meta data on separate
storage but </DIV>
<DIV>still leaving disk flushes and md flushes on. </DIV>
<DIV> </DIV>
<DIV>so i dont understand , does it request a flush from the backend
device every write request ? it sounds like synchronous write...</DIV>
<DIV> </DIV>
<DIV>Also i read that if i do have a reliable battery backed write cache
</DIV>
<DIV>i can use no-disk-flushes;
no-md-flushes; , but i wonder if it is only the
controller (with the battery backed write cache) that has
protection?</DIV>
<DIV> </DIV>
<DIV>Don't hardrives have their own volatile write cache of their own ? </DIV>
<DIV> </DIV>
<DIV>so in a case the controller passed the data to the HD but the hd kept it
in its cache and there was a power outage i would get
corruption?<BR><BR></DIV>
<DIV class=gmail_quote>On Fri, Jun 20, 2008 at 3:45 PM, Lars Ellenberg <<A href="mailto:lars.ellenberg@linbit.com">lars.ellenberg@linbit.com</A>>
wrote:<BR>
<BLOCKQUOTE class=gmail_quote style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<DIV>
<DIV></DIV>
<DIV class=Wj3C7c>On Thu, Jun 19, 2008 at 09:28:58PM +0200, Marcelo Azevedo
wrote:<BR>> After placing the metadata on a different spindle (HD) , i
was able to reach<BR>> almost close to native speed (1-2MB/s
less)<BR>><BR>> with metadata internal i was reaching tops around half
of the native speed ,<BR>> 37MB/s~ :<BR>> physical partition
-> drbd -> ext3<BR>> and<BR>> 63MB/s~ with physical
partition -> ext3<BR>> 61MB/s with metadata external, now
this is true for another strong machine .<BR>><BR>> This other machine
has hardware RAID1 with two :<BR>> Cheetah T10 series,<BR>> 146GB
,Serial Attached SCSI<BR>> Interface Speed: 3Gb/s<BR>> Spindle
Rotation Speed: 15,000 RPM<BR>> Performance: 10K<BR>> on an IBM 2G
Xeon server with 2 dual cpu packages , each cpu with 4 cores . IBM<BR>>
ServeRAID SCSI controllers<BR>> 4GB of ram<BR>> native speed
-hardware raid1 -> physical partition -> ext3 is around
110MB/s<BR>> ( still isn't this a bit slow for this HD ? )<BR>>
hardware raid1 -> physical partition -> drbd -> ext3 - 101MB/s
with<BR>> external metadata on a USB2 connected SATA HD 7,200
rpm<BR>><BR>> now this is the crazy part - 8.3MB/s~ write speed
! with internal metadata ,<BR>> and 150MB/s read speed..<BR>> this
test was repeated with bonnie , iozone and dd , all showed around
same<BR>> numbers ,<BR>> i mean why the huge jump from 8MB/s to
100MB/s when using external metadata ,<BR>> and should this be STRESSED
on the Docs or when starting the program that<BR>> putting the metadata
on external media improves performance significantly? ,<BR>> still
i don't understand why i was able to reach only 8MB/s write speed on
this<BR>> strong server , maybe because of the hardware raid1
underneath?<BR><BR></DIV></DIV><A href="http://www.drbd.org/users-guide/ch-internals.html#s-metadata">http://www.drbd.org/users-guide/ch-internals.html#s-metadata</A><BR> ->
internal meta data<BR> -> disadvantages<BR><BR>"head movements" aka
seek time.<BR><BR>if you use internal meta data on the same single
spindle,<BR>without a decent battery backed write cache,<BR>you want to
configure a large-ish al-extents,<BR>so drbd meta data updates happen
infrequently.<BR><BR>--<BR>: Lars Ellenberg
<A href="http://www.linbit.com/">http://www.linbit.com</A> :<BR>: DRBD/HA
support and consulting sales at <A href="http://linbit.com/">linbit.com</A> :<BR>: LINBIT Information
Technologies GmbH Tel +43-1-8178292-0 :<BR>:
Vivenotgasse 48, A-1120 Vienna/Europe Fax +43-1-8178292-82
:<BR>__<BR>please don't Cc me, but send to list -- I'm
subscribed<BR>_______________________________________________<BR>drbd-user
mailing list<BR><A href="mailto:drbd-user@lists.linbit.com">drbd-user@lists.linbit.com</A><BR><A href="http://lists.linbit.com/mailman/listinfo/drbd-user">http://lists.linbit.com/mailman/listinfo/drbd-user</A><BR></BLOCKQUOTE></DIV><BR></BLOCKQUOTE></BODY><!--[object_id=#titaninternet.co.uk#]--><FONT face=Tahoma size=2><FONT color=#0000ff>
<P align=center>
<HR>
</P>
<P align=left>This email may contain legally privileged and/or confidential information. It is solely for and is confidential for use by the addressee. Unauthorised recipients must preserve, observe and respect this confidentiality. If you have received it in error please notify us and delete it from your computer. Do not discuss, distribute or otherwise copy it. </FONT></FONT></P>
<P align=left><FONT face=Tahoma size=2><FONT color=#0000ff>Unless expressly stated to the contrary this e-mail is not intended to, and shall not, have any contractually binding effect on the Company and its clients. We accept no liability for any reliance placed on this e-mail other than to the intended recipient. If the content is not about the business of this Company or its clients then the message is neither from nor sanctioned by the Company. </FONT></FONT></P>
<P align=left><FONT face=Tahoma size=2><FONT color=#0000ff>We accept no liability or responsibility for any changes made to this e-mail after it was sent or any viruses transmitted through this e-mail or any attachment. It is your responsibility to satisfy yourself that this e-mail or any attachment is free from viruses and can be opened without harm to your systems.</FONT></FONT></P>
<P align=left><FONT face=Tahoma color=#0000ff size=2></FONT> </P></HTML>