On Thu, Jan 13, 2011 at 2:07 PM, Mark Morlino <span dir="ltr"><<a href="mailto:mrmorlino@alaska.edu">mrmorlino@alaska.edu</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On Mon, Jan 10, 2011 at 10:31 AM, Bart Coninckx<br>
<div><div></div><div class="h5"><<a href="mailto:bart.coninckx@telenet.be">bart.coninckx@telenet.be</a>> wrote:<br>
> On Monday 10 January 2011 19:40:17 J. Ryan Earl wrote:<br>
>> On Sun, Jan 9, 2011 at 10:03 AM, Bart Coninckx<br>
> <<a href="mailto:bart.coninckx@telenet.be">bart.coninckx@telenet.be</a>>wrote:<br>
>> > Hi all,<br>
>> ><br>
>> > am reading the Novell docs on DRBD and one of the ways they mention to<br>
>> > speed<br>
>> > up DRBD is using external metadata. Possibly a hard question to answer<br>
>> > but could someone indicate by what degree this would enhance speed<br>
>> > (provided using<br>
>> > a sufficient fast disk for the metadata, like a SSD)?<br>
>> ><br>
>> > thx!<br>
>> ><br>
>> > Bart<br>
>><br>
>> A RAID controller with a backed-write cache essentially nullifies<br>
>> any advantage there. A RAID controller that can instantly return on<br>
>> FUA-writes is what you want.<br>
>> -JR<br>
><br>
> Hi,<br>
><br>
> so the essence of your answer is that this is not a matter of having metadata<br>
> internal or external, but rather of having the right RAID controller?<br>
> Do you have examples of these in the major brands (HP, Dell, ...) ?<br>
><br>
> thx!<br>
><br>
><br>
><br>
> B.<br>
</div></div><div class="im">> _______________________________________________<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" target="_blank">http://lists.linbit.com/mailman/listinfo/drbd-user</a><br>
><br>
<br>
</div>I would be interested in this information too (in my case I'd be<br>
interested in any supermicro controllers that meet this requirement).<br>
If I understand correctly, an FUA-write is a write-through request.<br>
Doesn't that mean that the controller should not return until<br>
everything has been physically written to the disk? It seems to me<br>
that in order to return instantly on an FUA-write, the controller<br>
would have to ignore the FUA request and return once the data has been<br>
written to the cache. I don't see how it can both force physical disk<br>
access and return instantly. Perhaps I'm missing something, it<br>
certainly wouldn't be the first time.</blockquote><div><br></div><div>So a backed-cache is a cache where power-failure won't cause the cache to lose it's contents. I'll go with the example of a HP P410i SmartArray Controller with 1GB of flash-backed write cache. In this case there is 1GB of DDR2-533 ECC memory on the RAID controller with 4.2GB/sec of bandwidth. To the OS, this particular card doesn't even register as having a write-cache, it indicates that all writes are write-through. However, the hardware does cache the writes to this memory. In the event of a power failure, there are capacitors that hold enough charge to write the contents of the DDR2 memory to a non-volitate flash memory device. Thus the reason it doesn't wait for disk. When power is restored, it'll finish writing the contents of the flash to disk.</div>
<div><br></div><div>So, the raid controller is returning as soon as it writes the request to write-cache, there is no latency component waiting for disk. In my tests, synchronous writes would return in under a microsecond versus the milliseconds you'd wait without a write cache on a mechanical drive. Also, SSDs can vary, but if you want rediculously sick I/O I'd suggest the PCI-express SSD cards like ioDrives from ioFusion.</div>
<div><br></div><div>-JR</div></div>