<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Dear Arnold,<br>
<br>
Thanks for your feedback.<br>
It's interesting because, normally, writes do not directly
translate to head seeks (thanks to dirty pages, caches, NCQ,
firmware-level optimization...), and ideally barriers should be
disabled (and caches reliable).<br>
Florian Haas once suggested[1] that "if using external metadata
actually improves your performance versus internal metadata, you
have underlying performance problems to fix."<br>
Have you been investigating this possibility?<br>
Or is the improvement specific to the type of write load your
server endures?<br>
<br>
Lionel.<br>
<br>
[1]
<a class="moz-txt-link-freetext" href="http://fghaas.wordpress.com/2009/08/20/internal-metadata-and-why-we-recommend-it/">http://fghaas.wordpress.com/2009/08/20/internal-metadata-and-why-we-recommend-it/</a><br>
<br>
Le 27/02/2013 23:13, Arnold Krille a écrit :
<pre wrap="">
</pre>
</div>
<blockquote
cite="mid:20130227231307.4c30c9f3@saratoga.arnoldarts.de"
type="cite">
<pre wrap="">My experience with an ssd for (external) meta-data says that imrovement
is quite a lot!
You won't get faster continous writes, that is still limited by the
hdd. But you get much faster random-writes and the reason is this:
- With internal meta-data on hdd, each write (or until each barrier)
is followed by a disk-seek to the end of the disk where the
meta-data lives followed by a seek back to where you are writing.
And then you mix random writes at random positions...
- With external meta-data on another hdd, your data-disk doesn't have
to seek to the end of the disk anymore, step one of improvement.
- With external meta-data on ssd, you are only left with the seeks
during your normal random writes.
With todays disks and normal usage (unless you are netflix or google),
the real speed-improvement your users see/feel is not faster throughput
but lower latency.
Of course, using internal meta-data with the whole partition on ssd
gives you the best performance, but not everyone can buy enough ssds to
create a mirrored 6TB array of ssd.
3x2TB hdd + 160G ssd (for meta-data and the fast-loving databases)
times two on the other hand is actually affordable...
As to the original authors question: There is a manpage about drbdmeta
which describes the options to dump and restore the meta-data of an
offline drbd. So the action will be:
- stop the drbd-volume
- dump the meta-data
- change the config to point the meta-data to the new place
- restore the meta-data
- restart the drbd-volume
- wait for sync (only incremental, not a full sync) and repeat with the
other node
I did that with several volumes when our ssds arrived. Test the steps
with a scrap-drbd-volume before doing the procedure on production-data
to be sure.
Have fun,
Arnold
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
drbd-user mailing list
<a class="moz-txt-link-abbreviated" href="mailto:drbd-user@lists.linbit.com">drbd-user@lists.linbit.com</a>
<a class="moz-txt-link-freetext" href="http://lists.linbit.com/mailman/listinfo/drbd-user">http://lists.linbit.com/mailman/listinfo/drbd-user</a>
</pre>
</blockquote>
<br>
</body>
</html>