Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
>From my understanding the internal metadata write penalty in your case is caused by seeks between the data and metadata parts of your disk. You may experiment with metadata on a different spindle, as this will allow you to dispatch data and metadata io in parallel. Most people run their DRBD backing store on top of raid--in this case, either a SAS or SATA (I'm running on FC disks). A simple 3 ware should have BBU, which should allow you to enable write-back caching. Good luck! cc On Mon, Sep 14, 2009 at 3:48 PM, Christian Iversen <chrivers at iversen-net.dk> wrote: > Hey DRBD-list > > I'm trying to build a reasonably performant DRBD-minicluster (2 machines > with heartbeat). I've got the basic setup working fine, with 2 largely > identical servers each running a Seagate 7200.ES 500GB disk. > > This is exported as a HA-NFS on top of the 500GB DRBD volume with internal > metadata. It's used in our production system, and we're generally very happy > with the result (failover, etc), except the performance leaves a bit to be > desired. > > I have a few questions: > > 1) It really seems internal metadata is a bad idea, since it eats 2 extra > seeks per write. Is this always true, or can DRBD sometimes buffer these > metadata-writes to minimize impact? > > 2) Suppose write latency (related to question #1) is our biggest concern. We > are currently using protocol C. Will protocol A or B be vastly different? I > know there's no substitute for a proper benchmarking, but we are a little > wary of "just testing something" on our production system. Does anybody have > experience with this they would like to share? > > 3) Suppose the write latency really is the biggest problem we're facing > (we're still investigating the situation). As far as I can tell, a > battery-backed storage controller is the way to go, since this will allow > persistent stores to complete right away. However, this is for a normal > server, not DRBD. How does DRBD affect this situation? Will such a > controller even be useful at all? > > 4) If it will be useful, can anybody recommend a good SATA battery backed > controller? > > > I look forward to hearing any comments you might have. > > P.S: I should note that we are not willing to sacrifice data integrity for > performance. If it seems that way from my comments about protocol A/B/C, let > me assure you that we simply want to learn about the various bottlenecks in > the system. > > -- > Med venlig hilsen > Christian Iversen > _______________________________________________ > drbd-user mailing list > drbd-user at lists.linbit.com > http://lists.linbit.com/mailman/listinfo/drbd-user > -- Chris Chen <muffaleta at gmail.com> "The fact that yours is better than anyone else's is not a guarantee that it's any good." -- Seen on a wall