Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Dear Arnold, Thanks for your feedback. 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). Florian Haas once suggested[1] that "if using external metadata actually improves your performance versus internal metadata, you have underlying performance problems to fix." Have you been investigating this possibility? Or is the improvement specific to the type of write load your server endures? Lionel. [1] http://fghaas.wordpress.com/2009/08/20/internal-metadata-and-why-we-recommend-it/ Le 27/02/2013 23:13, Arnold Krille a écrit : > 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 > > > _______________________________________________ > 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/20130228/c438b8b4/attachment.htm>