Thread: [SSI-devel] patch-drbd-0.7.8-ssi_rc5
Brought to you by:
brucewalker,
rogertsang
From: Roger T. <rog...@gm...> - 2005-03-25 02:23:11
Attachments:
patch-drbd-0.7.8-ssi_rc5.gz
|
This one should fix the bug introduced in rc4. Also some clean up of /etc/drbd.conf to reflect /dev/drbd0 has changed to /dev/drbd/0. Maybe drbd-0.7.10 doesn't have the /dev/drbd0 mistake in drbd.conf, so you might get patch rejects. Also clms subsys priority is moved back to 0. Limitations: I discovered that you can take down the initnode if it is drbd primary synctarget and you flood the network with a super high sync rate. You'll get drbd short read messages on the console of the failover initnode and the initnode will failover. What you should do is drop the sync rate down to an acceptable level so that background sync can complete. To duplicate this, failover the preferred initnode to your secondary initnode. After failover completes reboot both drbd nodes at the same time. The preferred initnode will mount drbd primary and become synctarget. -Roger |
From: Roger T. <rog...@gm...> - 2005-04-04 07:39:36
|
Additionally you may witness significant DRBD performance increases by tuning DRBD and your kernel network layer properly. The following changes to drbd.conf seems to be a good start in addition to tuning the kernel for gigabit. I'm getting close to raw disk IO performance after tuning. --- drbd.conf 24 Mar 2005 18:45:19 -0000 1.2.2.2 +++ drbd.conf 4 Apr 2005 07:26:55 -0000 @@ -167,6 +167,7 @@ # defaults to 2*65535; you might try even 1M, but if your kernel or # network driver chokes on that, you have been warned. # sndbuf-size 512k; + sndbuf-size 4M; # timeout 60; # 6 seconds (unit = 0.1 seconds) # connect-int 10; # 10 seconds (unit = 1 second) @@ -179,11 +180,12 @@ # datablocks while they are written to disk. # # max-buffers 2048; - max-buffers 4096; + max-buffers 8192; # The highest number of data blocks between two write barriers. # If you set this < 10 you might decrease your performance. # max-epoch-size 2048; + max-epoch-size 8192; # if some block send times out this many times, the peer is # considered dead, even if it still answers ping requests. On Mar 24, 2005 10:23 PM, Roger Tsang <rog...@gm...> wrote: > This one should fix the bug introduced in rc4. Also some clean up of > /etc/drbd.conf to reflect /dev/drbd0 has changed to /dev/drbd/0. > Maybe drbd-0.7.10 doesn't have the /dev/drbd0 mistake in drbd.conf, so > you might get patch rejects. Also clms subsys priority is moved back > to 0. > > Limitations: I discovered that you can take down the initnode if it > is drbd primary synctarget and you flood the network with a super high > sync rate. You'll get drbd short read messages on the console of the > failover initnode and the initnode will failover. What you should do > is drop the sync rate down to an acceptable level so that background > sync can complete. > > To duplicate this, failover the preferred initnode to your secondary > initnode. After failover completes reboot both drbd nodes at the same > time. The preferred initnode will mount drbd primary and become > synctarget. > > -Roger > > > |
From: En C. L. <en...@in...> - 2005-04-04 07:49:21
|
Hi Roger, I've tested failover with the drbd in the OPENSSI-DB-1-2-STABLE branch of the repository, and I'm considering releasing an rpm based on that for 1.2.2, without declaring it as stable. I think that we could merge your latest changes into the devel branch, and have it release with the 1.9 openssi based on a 2.6 kernel. What do you think? En Chiang Roger Tsang wrote: > Additionally you may witness significant DRBD performance increases by > tuning DRBD and your kernel network layer properly. The following > changes to drbd.conf seems to be a good start in addition to tuning > the kernel for gigabit. I'm getting close to raw disk IO performance > after tuning. > > --- drbd.conf 24 Mar 2005 18:45:19 -0000 1.2.2.2 > +++ drbd.conf 4 Apr 2005 07:26:55 -0000 > @@ -167,6 +167,7 @@ > # defaults to 2*65535; you might try even 1M, but if your kernel or > # network driver chokes on that, you have been warned. > # sndbuf-size 512k; > + sndbuf-size 4M; > > # timeout 60; # 6 seconds (unit = 0.1 seconds) > # connect-int 10; # 10 seconds (unit = 1 second) > @@ -179,11 +180,12 @@ > # datablocks while they are written to disk. > # > # max-buffers 2048; > - max-buffers 4096; > + max-buffers 8192; > > # The highest number of data blocks between two write barriers. > # If you set this < 10 you might decrease your performance. > # max-epoch-size 2048; > + max-epoch-size 8192; > > # if some block send times out this many times, the peer is > # considered dead, even if it still answers ping requests. > > > On Mar 24, 2005 10:23 PM, Roger Tsang <rog...@gm...> wrote: > >>This one should fix the bug introduced in rc4. Also some clean up of >>/etc/drbd.conf to reflect /dev/drbd0 has changed to /dev/drbd/0. >>Maybe drbd-0.7.10 doesn't have the /dev/drbd0 mistake in drbd.conf, so >>you might get patch rejects. Also clms subsys priority is moved back >>to 0. >> >>Limitations: I discovered that you can take down the initnode if it >>is drbd primary synctarget and you flood the network with a super high >>sync rate. You'll get drbd short read messages on the console of the >>failover initnode and the initnode will failover. What you should do >>is drop the sync rate down to an acceptable level so that background >>sync can complete. >> >>To duplicate this, failover the preferred initnode to your secondary >>initnode. After failover completes reboot both drbd nodes at the same >>time. The preferred initnode will mount drbd primary and become >>synctarget. >> >>-Roger >> >> >> > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > ssic-linux-devel mailing list > ssi...@li... > https://lists.sourceforge.net/lists/listinfo/ssic-linux-devel > > |
From: En C. L. <en...@in...> - 2005-04-04 09:10:22
|
Hi Roger, I've put a tarball with the drbd RPMS for 1.2.2 on fc2 on openssi.org. Please let me know if it is okay. The code is taken from the OPENSSI-DB-1-2-STABLE and is what is included in the 1.2.2 release of the debian version of 1.2.2. Regards, En Chiang En Chiang Lee wrote: > Hi Roger, > > I've tested failover with the drbd in the OPENSSI-DB-1-2-STABLE branch > of the repository, and I'm considering releasing an rpm based on that > for 1.2.2, without declaring it as stable. > > I think that we could merge your latest changes into the devel branch, > and have it release with the 1.9 openssi based on a 2.6 kernel. > > What do you think? > > En Chiang > > Roger Tsang wrote: > >> Additionally you may witness significant DRBD performance increases by >> tuning DRBD and your kernel network layer properly. The following >> changes to drbd.conf seems to be a good start in addition to tuning >> the kernel for gigabit. I'm getting close to raw disk IO performance >> after tuning. >> >> --- drbd.conf 24 Mar 2005 18:45:19 -0000 1.2.2.2 >> +++ drbd.conf 4 Apr 2005 07:26:55 -0000 >> @@ -167,6 +167,7 @@ >> # defaults to 2*65535; you might try even 1M, but if your kernel or >> # network driver chokes on that, you have been warned. >> # sndbuf-size 512k; >> + sndbuf-size 4M; >> >> # timeout 60; # 6 seconds (unit = 0.1 seconds) >> # connect-int 10; # 10 seconds (unit = 1 second) >> @@ -179,11 +180,12 @@ >> # datablocks while they are written to disk. >> # >> # max-buffers 2048; >> - max-buffers 4096; >> + max-buffers 8192; >> >> # The highest number of data blocks between two write barriers. >> # If you set this < 10 you might decrease your performance. >> # max-epoch-size 2048; >> + max-epoch-size 8192; >> >> # if some block send times out this many times, the peer is >> # considered dead, even if it still answers ping requests. >> >> >> On Mar 24, 2005 10:23 PM, Roger Tsang <rog...@gm...> wrote: >> >>> This one should fix the bug introduced in rc4. Also some clean up of >>> /etc/drbd.conf to reflect /dev/drbd0 has changed to /dev/drbd/0. >>> Maybe drbd-0.7.10 doesn't have the /dev/drbd0 mistake in drbd.conf, so >>> you might get patch rejects. Also clms subsys priority is moved back >>> to 0. >>> >>> Limitations: I discovered that you can take down the initnode if it >>> is drbd primary synctarget and you flood the network with a super high >>> sync rate. You'll get drbd short read messages on the console of the >>> failover initnode and the initnode will failover. What you should do >>> is drop the sync rate down to an acceptable level so that background >>> sync can complete. >>> >>> To duplicate this, failover the preferred initnode to your secondary >>> initnode. After failover completes reboot both drbd nodes at the same >>> time. The preferred initnode will mount drbd primary and become >>> synctarget. >>> >>> -Roger >>> >>> >>> >> >> >> >> ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT Products from real users. >> Discover which products truly live up to the hype. Start reading now. >> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> _______________________________________________ >> ssic-linux-devel mailing list >> ssi...@li... >> https://lists.sourceforge.net/lists/listinfo/ssic-linux-devel >> >> > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > ssic-linux-devel mailing list > ssi...@li... > https://lists.sourceforge.net/lists/listinfo/ssic-linux-devel > > |
From: Roger T. <rog...@gm...> - 2005-04-04 11:35:27
|
Hi, Which DRBD-SSI version is the Debian branch based on? rc5? rc4? I wanted to add the following to rc5 before you release it, but I prob won't be testing it until end of day. --- drbd/drbd_receiver.c 25 Mar 2005 02:08:39 -0000 1.2.2.17 +++ drbd/drbd_receiver.c 4 Apr 2005 10:08:33 -0000 @@ -2353,6 +2353,10 @@ clear_bit(SIGNAL_ASENDER, &mdev->flags); if (mdev->cstate >= Connected) set_cstate(mdev,NetworkFailure); +#ifdef CONFIG_CLMS + /* Do not race against drbd_nodedown(). */ + if CLMS_PEER_UP(mdev) +#endif drbd_thread_restart_nowait(&mdev->receiver); } -Roger On Apr 4, 2005 5:08 AM, En Chiang Lee <en...@in...> wrote: > Hi Roger, > > I've put a tarball with the drbd RPMS for 1.2.2 on fc2 on openssi.org. > Please let me know if it is okay. The code is taken from the > OPENSSI-DB-1-2-STABLE and is what is included in the 1.2.2 release of > the debian version of 1.2.2. > > Regards, > > En Chiang > > En Chiang Lee wrote: > > Hi Roger, > > > > I've tested failover with the drbd in the OPENSSI-DB-1-2-STABLE branch > > of the repository, and I'm considering releasing an rpm based on that > > for 1.2.2, without declaring it as stable. > > > > I think that we could merge your latest changes into the devel branch, > > and have it release with the 1.9 openssi based on a 2.6 kernel. > > > > What do you think? > > > > En Chiang > > > > Roger Tsang wrote: > > > >> Additionally you may witness significant DRBD performance increases by > >> tuning DRBD and your kernel network layer properly. The following > >> changes to drbd.conf seems to be a good start in addition to tuning > >> the kernel for gigabit. I'm getting close to raw disk IO performance > >> after tuning. > >> > >> --- drbd.conf 24 Mar 2005 18:45:19 -0000 1.2.2.2 > >> +++ drbd.conf 4 Apr 2005 07:26:55 -0000 > >> @@ -167,6 +167,7 @@ > >> # defaults to 2*65535; you might try even 1M, but if your kernel or > >> # network driver chokes on that, you have been warned. > >> # sndbuf-size 512k; > >> + sndbuf-size 4M; > >> > >> # timeout 60; # 6 seconds (unit = 0.1 seconds) > >> # connect-int 10; # 10 seconds (unit = 1 second) > >> @@ -179,11 +180,12 @@ > >> # datablocks while they are written to disk. > >> # > >> # max-buffers 2048; > >> - max-buffers 4096; > >> + max-buffers 8192; > >> > >> # The highest number of data blocks between two write barriers. > >> # If you set this < 10 you might decrease your performance. > >> # max-epoch-size 2048; > >> + max-epoch-size 8192; > >> > >> # if some block send times out this many times, the peer is > >> # considered dead, even if it still answers ping requests. > >> > >> > >> On Mar 24, 2005 10:23 PM, Roger Tsang <rog...@gm...> wrote: > >> > >>> This one should fix the bug introduced in rc4. Also some clean up of > >>> /etc/drbd.conf to reflect /dev/drbd0 has changed to /dev/drbd/0. > >>> Maybe drbd-0.7.10 doesn't have the /dev/drbd0 mistake in drbd.conf, so > >>> you might get patch rejects. Also clms subsys priority is moved back > >>> to 0. > >>> > >>> Limitations: I discovered that you can take down the initnode if it > >>> is drbd primary synctarget and you flood the network with a super high > >>> sync rate. You'll get drbd short read messages on the console of the > >>> failover initnode and the initnode will failover. What you should do > >>> is drop the sync rate down to an acceptable level so that background > >>> sync can complete. > >>> > >>> To duplicate this, failover the preferred initnode to your secondary > >>> initnode. After failover completes reboot both drbd nodes at the same > >>> time. The preferred initnode will mount drbd primary and become > >>> synctarget. > >>> > >>> -Roger > >>> > >>> > >>> > >> > >> > >> > >> ------------------------------------------------------- > >> SF email is sponsored by - The IT Product Guide > >> Read honest & candid reviews on hundreds of IT Products from real users. > >> Discover which products truly live up to the hype. Start reading now. > >> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > >> _______________________________________________ > >> ssic-linux-devel mailing list > >> ssi...@li... > >> https://lists.sourceforge.net/lists/listinfo/ssic-linux-devel > >> > >> > > > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product Guide > > Read honest & candid reviews on hundreds of IT Products from real users. > > Discover which products truly live up to the hype. Start reading now. > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > _______________________________________________ > > ssic-linux-devel mailing list > > ssi...@li... > > https://lists.sourceforge.net/lists/listinfo/ssic-linux-devel > > > > > |
From: En C. L. <en...@in...> - 2005-04-04 11:57:24
|
Hi Roger, The DRBD-SSI version is older than rc4, and since we should be doing 1.9 by the end of this month, I think we'll put >rc5 into the development branch and release it with 1.9. Regards, En Chiang Roger Tsang wrote: > Hi, > > Which DRBD-SSI version is the Debian branch based on? rc5? rc4? I > wanted to add the following to rc5 before you release it, but I prob > won't be testing it until end of day. > > --- drbd/drbd_receiver.c 25 Mar 2005 02:08:39 -0000 1.2.2.17 > +++ drbd/drbd_receiver.c 4 Apr 2005 10:08:33 -0000 > @@ -2353,6 +2353,10 @@ > clear_bit(SIGNAL_ASENDER, &mdev->flags); > if (mdev->cstate >= Connected) > set_cstate(mdev,NetworkFailure); > +#ifdef CONFIG_CLMS > + /* Do not race against drbd_nodedown(). */ > + if CLMS_PEER_UP(mdev) > +#endif > drbd_thread_restart_nowait(&mdev->receiver); > } > > > -Roger > > On Apr 4, 2005 5:08 AM, En Chiang Lee <en...@in...> wrote: > >>Hi Roger, >> >>I've put a tarball with the drbd RPMS for 1.2.2 on fc2 on openssi.org. >>Please let me know if it is okay. The code is taken from the >>OPENSSI-DB-1-2-STABLE and is what is included in the 1.2.2 release of >>the debian version of 1.2.2. >> >>Regards, >> >>En Chiang >> >>En Chiang Lee wrote: >> >>>Hi Roger, >>> >>>I've tested failover with the drbd in the OPENSSI-DB-1-2-STABLE branch >>>of the repository, and I'm considering releasing an rpm based on that >>>for 1.2.2, without declaring it as stable. >>> >>>I think that we could merge your latest changes into the devel branch, >>>and have it release with the 1.9 openssi based on a 2.6 kernel. >>> >>>What do you think? >>> >>>En Chiang >>> >>>Roger Tsang wrote: >>> >>> >>>>Additionally you may witness significant DRBD performance increases by >>>>tuning DRBD and your kernel network layer properly. The following >>>>changes to drbd.conf seems to be a good start in addition to tuning >>>>the kernel for gigabit. I'm getting close to raw disk IO performance >>>>after tuning. >>>> >>>>--- drbd.conf 24 Mar 2005 18:45:19 -0000 1.2.2.2 >>>>+++ drbd.conf 4 Apr 2005 07:26:55 -0000 >>>>@@ -167,6 +167,7 @@ >>>> # defaults to 2*65535; you might try even 1M, but if your kernel or >>>> # network driver chokes on that, you have been warned. >>>> # sndbuf-size 512k; >>>>+ sndbuf-size 4M; >>>> >>>> # timeout 60; # 6 seconds (unit = 0.1 seconds) >>>> # connect-int 10; # 10 seconds (unit = 1 second) >>>>@@ -179,11 +180,12 @@ >>>> # datablocks while they are written to disk. >>>> # >>>> # max-buffers 2048; >>>>- max-buffers 4096; >>>>+ max-buffers 8192; >>>> >>>> # The highest number of data blocks between two write barriers. >>>> # If you set this < 10 you might decrease your performance. >>>> # max-epoch-size 2048; >>>>+ max-epoch-size 8192; >>>> >>>> # if some block send times out this many times, the peer is >>>># considered dead, even if it still answers ping requests. >>>> >>>> >>>>On Mar 24, 2005 10:23 PM, Roger Tsang <rog...@gm...> wrote: >>>> >>>> >>>>>This one should fix the bug introduced in rc4. Also some clean up of >>>>>/etc/drbd.conf to reflect /dev/drbd0 has changed to /dev/drbd/0. >>>>>Maybe drbd-0.7.10 doesn't have the /dev/drbd0 mistake in drbd.conf, so >>>>>you might get patch rejects. Also clms subsys priority is moved back >>>>>to 0. >>>>> >>>>>Limitations: I discovered that you can take down the initnode if it >>>>>is drbd primary synctarget and you flood the network with a super high >>>>>sync rate. You'll get drbd short read messages on the console of the >>>>>failover initnode and the initnode will failover. What you should do >>>>>is drop the sync rate down to an acceptable level so that background >>>>>sync can complete. >>>>> >>>>>To duplicate this, failover the preferred initnode to your secondary >>>>>initnode. After failover completes reboot both drbd nodes at the same >>>>>time. The preferred initnode will mount drbd primary and become >>>>>synctarget. >>>>> >>>>>-Roger >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>>------------------------------------------------------- >>>>SF email is sponsored by - The IT Product Guide >>>>Read honest & candid reviews on hundreds of IT Products from real users. >>>>Discover which products truly live up to the hype. Start reading now. >>>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >>>>_______________________________________________ >>>>ssic-linux-devel mailing list >>>>ssi...@li... >>>>https://lists.sourceforge.net/lists/listinfo/ssic-linux-devel >>>> >>>> >>> >>> >>>------------------------------------------------------- >>>SF email is sponsored by - The IT Product Guide >>>Read honest & candid reviews on hundreds of IT Products from real users. >>>Discover which products truly live up to the hype. Start reading now. >>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >>>_______________________________________________ >>>ssic-linux-devel mailing list >>>ssi...@li... >>>https://lists.sourceforge.net/lists/listinfo/ssic-linux-devel >>> >>> >> > > |
From: Roger T. <rog...@gm...> - 2005-04-04 11:38:04
|
Also I was curious what kind of performance you were getting on your hardware. Were you getting close to raw disk IO performance for sync or while drbd connected? -Roger On Apr 4, 2005 5:08 AM, En Chiang Lee <en...@in...> wrote: > Hi Roger, > > I've put a tarball with the drbd RPMS for 1.2.2 on fc2 on openssi.org. > Please let me know if it is okay. The code is taken from the > OPENSSI-DB-1-2-STABLE and is what is included in the 1.2.2 release of > the debian version of 1.2.2. > > Regards, > > En Chiang > > En Chiang Lee wrote: > > Hi Roger, > > > > I've tested failover with the drbd in the OPENSSI-DB-1-2-STABLE branch > > of the repository, and I'm considering releasing an rpm based on that > > for 1.2.2, without declaring it as stable. > > > > I think that we could merge your latest changes into the devel branch, > > and have it release with the 1.9 openssi based on a 2.6 kernel. > > > > What do you think? > > > > En Chiang > > > > Roger Tsang wrote: > > > >> Additionally you may witness significant DRBD performance increases by > >> tuning DRBD and your kernel network layer properly. The following > >> changes to drbd.conf seems to be a good start in addition to tuning > >> the kernel for gigabit. I'm getting close to raw disk IO performance > >> after tuning. > >> > >> --- drbd.conf 24 Mar 2005 18:45:19 -0000 1.2.2.2 > >> +++ drbd.conf 4 Apr 2005 07:26:55 -0000 > >> @@ -167,6 +167,7 @@ > >> # defaults to 2*65535; you might try even 1M, but if your kernel or > >> # network driver chokes on that, you have been warned. > >> # sndbuf-size 512k; > >> + sndbuf-size 4M; > >> > >> # timeout 60; # 6 seconds (unit = 0.1 seconds) > >> # connect-int 10; # 10 seconds (unit = 1 second) > >> @@ -179,11 +180,12 @@ > >> # datablocks while they are written to disk. > >> # > >> # max-buffers 2048; > >> - max-buffers 4096; > >> + max-buffers 8192; > >> > >> # The highest number of data blocks between two write barriers. > >> # If you set this < 10 you might decrease your performance. > >> # max-epoch-size 2048; > >> + max-epoch-size 8192; > >> > >> # if some block send times out this many times, the peer is > >> # considered dead, even if it still answers ping requests. > >> > >> > >> On Mar 24, 2005 10:23 PM, Roger Tsang <rog...@gm...> wrote: > >> > >>> This one should fix the bug introduced in rc4. Also some clean up of > >>> /etc/drbd.conf to reflect /dev/drbd0 has changed to /dev/drbd/0. > >>> Maybe drbd-0.7.10 doesn't have the /dev/drbd0 mistake in drbd.conf, so > >>> you might get patch rejects. Also clms subsys priority is moved back > >>> to 0. > >>> > >>> Limitations: I discovered that you can take down the initnode if it > >>> is drbd primary synctarget and you flood the network with a super high > >>> sync rate. You'll get drbd short read messages on the console of the > >>> failover initnode and the initnode will failover. What you should do > >>> is drop the sync rate down to an acceptable level so that background > >>> sync can complete. > >>> > >>> To duplicate this, failover the preferred initnode to your secondary > >>> initnode. After failover completes reboot both drbd nodes at the same > >>> time. The preferred initnode will mount drbd primary and become > >>> synctarget. > >>> > >>> -Roger > >>> > >>> > >>> > >> > >> > >> > >> ------------------------------------------------------- > >> SF email is sponsored by - The IT Product Guide > >> Read honest & candid reviews on hundreds of IT Products from real users. > >> Discover which products truly live up to the hype. Start reading now. > >> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > >> _______________________________________________ > >> ssic-linux-devel mailing list > >> ssi...@li... > >> https://lists.sourceforge.net/lists/listinfo/ssic-linux-devel > >> > >> > > > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product Guide > > Read honest & candid reviews on hundreds of IT Products from real users. > > Discover which products truly live up to the hype. Start reading now. > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > _______________________________________________ > > ssic-linux-devel mailing list > > ssi...@li... > > https://lists.sourceforge.net/lists/listinfo/ssic-linux-devel > > > > > |
From: Roger T. <rog...@gm...> - 2005-04-04 12:45:43
|
Actually the following depends on your hardware, on some hardware the default settings built into DRBD give better performance than the tweaks I've given below. -Roger On Apr 4, 2005 3:39 AM, Roger Tsang <rog...@gm...> wrote: > Additionally you may witness significant DRBD performance increases by > tuning DRBD and your kernel network layer properly. The following > changes to drbd.conf seems to be a good start in addition to tuning > the kernel for gigabit. I'm getting close to raw disk IO performance > after tuning. > > --- drbd.conf 24 Mar 2005 18:45:19 -0000 1.2.2.2 > +++ drbd.conf 4 Apr 2005 07:26:55 -0000 > @@ -167,6 +167,7 @@ > # defaults to 2*65535; you might try even 1M, but if your kernel or > # network driver chokes on that, you have been warned. > # sndbuf-size 512k; > + sndbuf-size 4M; > > # timeout 60; # 6 seconds (unit = 0.1 seconds) > # connect-int 10; # 10 seconds (unit = 1 second) > @@ -179,11 +180,12 @@ > # datablocks while they are written to disk. > # > # max-buffers 2048; > - max-buffers 4096; > + max-buffers 8192; > > # The highest number of data blocks between two write barriers. > # If you set this < 10 you might decrease your performance. > # max-epoch-size 2048; > + max-epoch-size 8192; > > # if some block send times out this many times, the peer is > # considered dead, even if it still answers ping requests. > > > On Mar 24, 2005 10:23 PM, Roger Tsang <rog...@gm...> wrote: > > This one should fix the bug introduced in rc4. Also some clean up of > > /etc/drbd.conf to reflect /dev/drbd0 has changed to /dev/drbd/0. > > Maybe drbd-0.7.10 doesn't have the /dev/drbd0 mistake in drbd.conf, so > > you might get patch rejects. Also clms subsys priority is moved back > > to 0. > > > > Limitations: I discovered that you can take down the initnode if it > > is drbd primary synctarget and you flood the network with a super high > > sync rate. You'll get drbd short read messages on the console of the > > failover initnode and the initnode will failover. What you should do > > is drop the sync rate down to an acceptable level so that background > > sync can complete. > > > > To duplicate this, failover the preferred initnode to your secondary > > initnode. After failover completes reboot both drbd nodes at the same > > time. The preferred initnode will mount drbd primary and become > > synctarget. > > > > -Roger > > > > > > > |
From: En C. L. <en...@in...> - 2005-04-04 11:43:00
|
The performance with drbd connected was significantly slower than without... I don't have a measurement. It's just the impression I get when I'm using drbd. En Chiang Roger Tsang wrote: > Also I was curious what kind of performance you were getting on your > hardware. Were you getting close to raw disk IO performance for sync > or while drbd connected? > > -Roger > > On Apr 4, 2005 5:08 AM, En Chiang Lee <en...@in...> wrote: > >>Hi Roger, >> >>I've put a tarball with the drbd RPMS for 1.2.2 on fc2 on openssi.org. >>Please let me know if it is okay. The code is taken from the >>OPENSSI-DB-1-2-STABLE and is what is included in the 1.2.2 release of >>the debian version of 1.2.2. >> >>Regards, >> >>En Chiang >> >>En Chiang Lee wrote: >> >>>Hi Roger, >>> >>>I've tested failover with the drbd in the OPENSSI-DB-1-2-STABLE branch >>>of the repository, and I'm considering releasing an rpm based on that >>>for 1.2.2, without declaring it as stable. >>> >>>I think that we could merge your latest changes into the devel branch, >>>and have it release with the 1.9 openssi based on a 2.6 kernel. >>> >>>What do you think? >>> >>>En Chiang >>> >>>Roger Tsang wrote: >>> >>> >>>>Additionally you may witness significant DRBD performance increases by >>>>tuning DRBD and your kernel network layer properly. The following >>>>changes to drbd.conf seems to be a good start in addition to tuning >>>>the kernel for gigabit. I'm getting close to raw disk IO performance >>>>after tuning. >>>> >>>>--- drbd.conf 24 Mar 2005 18:45:19 -0000 1.2.2.2 >>>>+++ drbd.conf 4 Apr 2005 07:26:55 -0000 >>>>@@ -167,6 +167,7 @@ >>>> # defaults to 2*65535; you might try even 1M, but if your kernel or >>>> # network driver chokes on that, you have been warned. >>>> # sndbuf-size 512k; >>>>+ sndbuf-size 4M; >>>> >>>> # timeout 60; # 6 seconds (unit = 0.1 seconds) >>>> # connect-int 10; # 10 seconds (unit = 1 second) >>>>@@ -179,11 +180,12 @@ >>>> # datablocks while they are written to disk. >>>> # >>>> # max-buffers 2048; >>>>- max-buffers 4096; >>>>+ max-buffers 8192; >>>> >>>> # The highest number of data blocks between two write barriers. >>>> # If you set this < 10 you might decrease your performance. >>>> # max-epoch-size 2048; >>>>+ max-epoch-size 8192; >>>> >>>> # if some block send times out this many times, the peer is >>>># considered dead, even if it still answers ping requests. >>>> >>>> >>>>On Mar 24, 2005 10:23 PM, Roger Tsang <rog...@gm...> wrote: >>>> >>>> >>>>>This one should fix the bug introduced in rc4. Also some clean up of >>>>>/etc/drbd.conf to reflect /dev/drbd0 has changed to /dev/drbd/0. >>>>>Maybe drbd-0.7.10 doesn't have the /dev/drbd0 mistake in drbd.conf, so >>>>>you might get patch rejects. Also clms subsys priority is moved back >>>>>to 0. >>>>> >>>>>Limitations: I discovered that you can take down the initnode if it >>>>>is drbd primary synctarget and you flood the network with a super high >>>>>sync rate. You'll get drbd short read messages on the console of the >>>>>failover initnode and the initnode will failover. What you should do >>>>>is drop the sync rate down to an acceptable level so that background >>>>>sync can complete. >>>>> >>>>>To duplicate this, failover the preferred initnode to your secondary >>>>>initnode. After failover completes reboot both drbd nodes at the same >>>>>time. The preferred initnode will mount drbd primary and become >>>>>synctarget. >>>>> >>>>>-Roger >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>>------------------------------------------------------- >>>>SF email is sponsored by - The IT Product Guide >>>>Read honest & candid reviews on hundreds of IT Products from real users. >>>>Discover which products truly live up to the hype. Start reading now. >>>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >>>>_______________________________________________ >>>>ssic-linux-devel mailing list >>>>ssi...@li... >>>>https://lists.sourceforge.net/lists/listinfo/ssic-linux-devel >>>> >>>> >>> >>> >>>------------------------------------------------------- >>>SF email is sponsored by - The IT Product Guide >>>Read honest & candid reviews on hundreds of IT Products from real users. >>>Discover which products truly live up to the hype. Start reading now. >>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >>>_______________________________________________ >>>ssic-linux-devel mailing list >>>ssi...@li... >>>https://lists.sourceforge.net/lists/listinfo/ssic-linux-devel >>> >>> >> > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > ssic-linux-devel mailing list > ssi...@li... > https://lists.sourceforge.net/lists/listinfo/ssic-linux-devel > > |
From: Roger T. <rog...@gm...> - 2005-04-12 02:24:51
|
About the DRBD performance, can you try with a SSI kernel recompiled to support minimum PIII/Coppermine or higher rather than P2? I seem to be getting approx. 100% increase in sync performance with a P3 kernel. -Roger On Apr 4, 2005 7:41 AM, En Chiang Lee <en...@in...> wrote: > The performance with drbd connected was significantly slower than > without... I don't have a measurement. It's just the impression I get > when I'm using drbd. > > En Chiang > > Roger Tsang wrote: > > Also I was curious what kind of performance you were getting on your > > hardware. Were you getting close to raw disk IO performance for sync > > or while drbd connected? > > > > -Roger > > > > On Apr 4, 2005 5:08 AM, En Chiang Lee <en...@in...> wrote: > > > >>Hi Roger, > >> > >>I've put a tarball with the drbd RPMS for 1.2.2 on fc2 on openssi.org. > >>Please let me know if it is okay. The code is taken from the > >>OPENSSI-DB-1-2-STABLE and is what is included in the 1.2.2 release of > >>the debian version of 1.2.2. > >> > >>Regards, > >> > >>En Chiang > >> > >>En Chiang Lee wrote: > >> > >>>Hi Roger, > >>> > >>>I've tested failover with the drbd in the OPENSSI-DB-1-2-STABLE branch > >>>of the repository, and I'm considering releasing an rpm based on that > >>>for 1.2.2, without declaring it as stable. > >>> > >>>I think that we could merge your latest changes into the devel branch, > >>>and have it release with the 1.9 openssi based on a 2.6 kernel. > >>> > >>>What do you think? > >>> > >>>En Chiang > >>> > >>>Roger Tsang wrote: > >>> > >>> > >>>>Additionally you may witness significant DRBD performance increases by > >>>>tuning DRBD and your kernel network layer properly. The following > >>>>changes to drbd.conf seems to be a good start in addition to tuning > >>>>the kernel for gigabit. I'm getting close to raw disk IO performance > >>>>after tuning. > >>>> > >>>>--- drbd.conf 24 Mar 2005 18:45:19 -0000 1.2.2.2 > >>>>+++ drbd.conf 4 Apr 2005 07:26:55 -0000 > >>>>@@ -167,6 +167,7 @@ > >>>> # defaults to 2*65535; you might try even 1M, but if your kernel or > >>>> # network driver chokes on that, you have been warned. > >>>> # sndbuf-size 512k; > >>>>+ sndbuf-size 4M; > >>>> > >>>> # timeout 60; # 6 seconds (unit = 0.1 seconds) > >>>> # connect-int 10; # 10 seconds (unit = 1 second) > >>>>@@ -179,11 +180,12 @@ > >>>> # datablocks while they are written to disk. > >>>> # > >>>> # max-buffers 2048; > >>>>- max-buffers 4096; > >>>>+ max-buffers 8192; > >>>> > >>>> # The highest number of data blocks between two write barriers. > >>>> # If you set this < 10 you might decrease your performance. > >>>> # max-epoch-size 2048; > >>>>+ max-epoch-size 8192; > >>>> > >>>> # if some block send times out this many times, the peer is > >>>># considered dead, even if it still answers ping requests. > >>>> > >>>> > >>>>On Mar 24, 2005 10:23 PM, Roger Tsang <rog...@gm...> wrote: > >>>> > >>>> > >>>>>This one should fix the bug introduced in rc4. Also some clean up of > >>>>>/etc/drbd.conf to reflect /dev/drbd0 has changed to /dev/drbd/0. > >>>>>Maybe drbd-0.7.10 doesn't have the /dev/drbd0 mistake in drbd.conf, so > >>>>>you might get patch rejects. Also clms subsys priority is moved back > >>>>>to 0. > >>>>> > >>>>>Limitations: I discovered that you can take down the initnode if it > >>>>>is drbd primary synctarget and you flood the network with a super high > >>>>>sync rate. You'll get drbd short read messages on the console of the > >>>>>failover initnode and the initnode will failover. What you should do > >>>>>is drop the sync rate down to an acceptable level so that background > >>>>>sync can complete. > >>>>> > >>>>>To duplicate this, failover the preferred initnode to your secondary > >>>>>initnode. After failover completes reboot both drbd nodes at the same > >>>>>time. The preferred initnode will mount drbd primary and become > >>>>>synctarget. > >>>>> > >>>>>-Roger > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>>>------------------------------------------------------- > >>>>SF email is sponsored by - The IT Product Guide > >>>>Read honest & candid reviews on hundreds of IT Products from real users. > >>>>Discover which products truly live up to the hype. Start reading now. > >>>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > >>>>_______________________________________________ > >>>>ssic-linux-devel mailing list > >>>>ssi...@li... > >>>>https://lists.sourceforge.net/lists/listinfo/ssic-linux-devel > >>>> > >>>> > >>> > >>> > >>>------------------------------------------------------- > >>>SF email is sponsored by - The IT Product Guide > >>>Read honest & candid reviews on hundreds of IT Products from real users. > >>>Discover which products truly live up to the hype. Start reading now. > >>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > >>>_______________________________________________ > >>>ssic-linux-devel mailing list > >>>ssi...@li... > >>>https://lists.sourceforge.net/lists/listinfo/ssic-linux-devel > >>> > >>> > >> > > > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product Guide > > Read honest & candid reviews on hundreds of IT Products from real users. > > Discover which products truly live up to the hype. Start reading now. > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > _______________________________________________ > > ssic-linux-devel mailing list > > ssi...@li... > > https://lists.sourceforge.net/lists/listinfo/ssic-linux-devel > > > > > |