[DRBD-user] Antwort: Re: difference in speed when using external metadata

Robert.Koeppl at knapp.com Robert.Koeppl at knapp.com
Fri Jan 14 11:23:59 CET 2011

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


External metadata brings some advantages over internal metadata, especialy 
when it comes to resizing as well as recovery. If you want to maximize 
speed for metadata you could use a ssd connected to a dedicated 
controller. Given the small diskspace needed for metadata and the rather 
low price of such ssd nowadays this is probably the best solution. if you 
want to migrate existing partitions to DRBD external metadata AFAIK is the 
only way to do it
Mit freundlichen Grüßen / Best Regards

Robert Köppl

Systemadministration

KNAPP Systemintegration GmbH
Waltenbachstraße 9
8700 Leoben, Austria 
Phone: +43 3842 805-910
Fax: +43 3842 82930-500
robert.koeppl at knapp.com 
www.KNAPP.com 

Commercial register number: FN 138870x
Commercial register court: Leoben

The information in this e-mail (including any attachment) is confidential 
and intended to be for the use of the addressee(s) only. If you have 
received the e-mail by mistake, any disclosure, copy, distribution or use 
of the contents of the e-mail is prohibited, and you must delete the 
e-mail from your system. As e-mail can be changed electronically KNAPP 
assumes no responsibility for any alteration to this e-mail or its 
attachments. KNAPP has taken every reasonable precaution to ensure that 
any attachment to this e-mail has been swept for virus. However, KNAPP 
does not accept any liability for damage sustained as a result of such 
attachment being virus infected and strongly recommend that you carry out 
your own virus check before opening any attachment.



Mark Morlino <mrmorlino at alaska.edu> 
Gesendet von: drbd-user-bounces at lists.linbit.com
14.01.2011 08:40

An
drbd-user at lists.linbit.com
Kopie

Thema
Re: [DRBD-user] difference in speed when using external metadata






On Mon, Jan 10, 2011 at 10:31 AM, Bart Coninckx
<bart.coninckx at telenet.be> wrote:
> On Monday 10 January 2011 19:40:17 J. Ryan Earl wrote:
>> On Sun, Jan 9, 2011 at 10:03 AM, Bart Coninckx
> <bart.coninckx at telenet.be>wrote:
>> > Hi all,
>> >
>> > am reading the Novell docs on DRBD and one of the ways they mention 
to
>> > speed
>> > up DRBD is using external metadata. Possibly a hard question to 
answer
>> > but could someone indicate by what degree this would enhance speed
>> > (provided using
>> > a sufficient fast disk for the metadata, like a SSD)?
>> >
>> > thx!
>> >
>> > Bart
>>
>> A RAID controller with a backed-write cache essentially nullifies
>> any advantage there.  A RAID controller that can instantly return on
>> FUA-writes is what you want.
>> -JR
>
> Hi,
>
> so the essence of your answer is that this is not a matter of having 
metadata
> internal or external, but rather of having the right RAID controller?
> Do you have examples of these in the major brands (HP, Dell, ...) ?
>
> thx!
>
>
>
> B.
> _______________________________________________
> drbd-user mailing list
> drbd-user at lists.linbit.com
> http://lists.linbit.com/mailman/listinfo/drbd-user
>

I would be interested in this information too (in my case I'd be
interested in any supermicro controllers that meet this requirement).
If I understand correctly, an FUA-write is a write-through request.
Doesn't that mean that the controller should not return until
everything has been physically written to the disk? It seems to me
that in order to return instantly on an FUA-write, the controller
would have to ignore the FUA request and return once the data has been
written to the cache. I don't see how it can both force physical disk
access and return instantly. Perhaps I'm missing something, it
certainly wouldn't be the first time.

-Mark
_______________________________________________
drbd-user mailing list
drbd-user at lists.linbit.com
http://lists.linbit.com/mailman/listinfo/drbd-user

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20110114/72613c6c/attachment.htm>


More information about the drbd-user mailing list