Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Fri, Jun 22, 2007 at 12:13:06PM +0200, 01flipstar at web.de wrote: > Hi List, > > im new in drbd and ha-linux but in the last days i have spend quite some > time with my little setup. > > Setup 2 PC's each: > ~1GHz CPU > ~ 512 MB/Ram > 100MB LAN > > DRBD-0.8.0.3 > Kernel 2.6.21.3 > Suse 10.2 > > What I want is a OCFS2 partition on top of a drbd (activ/activ) setup. > > Everything works so fare but it was quite hard to find out that: > > - in a activ/activ setup only protocoll C is supported -> found in the > sourcecode only (call me optimist) hm. I thought that would be obvious ... I'll add a not to the "allow-two-primaries" paragraph in the man page. > The problem is that when both pc's concurrently write to one file the > performance gets really bad. > > My benchmark writes single lines with write() into a file, for one > minute the overall throughput is ok but for some lines it takes > about 300-500msec. > > I created two kernel one with preemption and timefreq=1000 and one > without preemption and timefreq=100 but the times did not vary. > > Maybe the DLM is the bottleneck?? of course it is. > I thought that I could improve the performance by not writing > the mata-data to the disk but to a ramdisk -> yes for tesing only :-) uh oh. well, you already said you are an optimist. > because the meta-data gets updated by very change on the disk right?? no. but it does not matter here anyways. it is drbd meta data. it has nothing to do with bouncing ocfs locks between nodes. > so the disk-head has to be moved and can not write sequential??? > So I tryed to add > > meta-disk /dev/ram0[0]; > > to my /etc/drbd.conf. > When I create the meta-data I get: > > Command 'drbdmeta /dev/drbd0 v08 /dev/ram0 0 write-dev-uuid > 587CBE437E1F2D14' terminated with exit code 255 > > The Ramdisk is > 128MB so this should not be the problem. > > > Is there a way to get the meta-data on a ramdisk? I'm not sure, I never tried, it does not make sense anyways. and it would not help you either. > Has somebody experiences with ocfs2 and drbd and can give me a hint > what to change?? when you care about performance on a cluster file system: don't write to the same file on more than one node at a time. try to not even read a file that is currently being written to by someone else. if you can avoid it, don't even access the same directories from more than on node, if one node is known to create/modify many files there. and nothing of that has anything to do with drbd, yet. it is all about latency of lock bouncing, cache coherence, cache invalidation and therfore necessary rereads from storage. -- : Lars Ellenberg Tel +43-1-8178292-0 : : LINBIT Information Technologies GmbH Fax +43-1-8178292-82 : : Vivenotgasse 48, A-1120 Vienna/Europe http://www.linbit.com : __ please use the "List-Reply" function of your email client.