[DRBD-user] how do i know it works?

[Lars Ellenberg]

/ 2004-05-29 12:10:13 -0700
\ Gregory Golin:
> Hello,
> 
> First of all, thank you for coming up with drbd and taking the time to
> improve it.
> 
> Here's my input.
> I have configured two systems, closely following the howto and after
> some tweaking was even able to get 'decent' sync speeds - around
> 50Mb/sec.
> 
> Here's my setup:
> 
> Two identical servers with the following configuration.
> Dual Xeons on a 7501 Westville mobo, 40GB IDE drive (OS), 2 73GB SCSI
> drives arranged in a RAID-1 (data) on Adaptec AIC7902 Hostraid
> controller, SuSE 8.2
> The servers are connected via a dedicated gig-E interface.
> 
> Some questions i would like to ask:
> 
> How do i know it works? From what i read, its a nono to mount the lower
> device on the secondary system. I did it anyway, >:D just to see if
> there is anything there. So after sync, yes, there was data. Then i
> copied around 250Mb to nb0 on the primary system and waited - nothing.
> Remounted /dev/sda1 - and its still empty. Thoughts?

you know that it works, if you use it as intended, and fail over.
if you don't use it as intended, thats not my problem :)

> Also, is there a way to watch replication live? Other than cat
> /proc/drbd ?

what would you like to have? maybe
 watch -n3 cat /proc/drbd 
is what you want?

> I tried tcpdump -i eth1 but its just a mess. One thing i
> noticed tho, an obscene number of packets is dropped by the secondary
> system. So any ideas in this area are welcome. (iptables is off.)

well, those packets are not "dropped by the system", but dropped by the
interface that tcpdump uses, because it does not make sense to slow down
the network traffic just because you want to sniff it. tcpdump (that
interface) just cannot keep up with the traffic.
it slightly improves if you tcpdump -s0 -w some-file, but not really,
and for sure not with Gig-E.

> Notes about the docs:
> Tabs in conf files confuse drbd, had to find that out the hard way.

hm. ok, tabs directly after tokens which are not assignments,
i.e. after keywords like "net<tab>{". hey, bash parsing config files :)
patch below fixes this. would have been faster to find, if you had given
some *example*, not only complained unspecifically.

> Some docs have dashes in conf file keywords - those dashes arent
> relevant anymore.

unless you be more specific and prove that,
I believe this statement is just plain wrong.

	Lars Ellenberg

----

diff -u -p -r1.57 drbd
--- drbd	28 Apr 2004 07:57:15 -0000	1.57
+++ drbd	1 Jun 2004 08:09:41 -0000
@@ -612,7 +612,7 @@ get_token() # {{{2
 			TOKEN_LINE=''
 			;;
 		*)
-			TOKEN=${TOKEN_LINE%% *}
+			TOKEN=${TOKEN_LINE%%[$IFS]*}
 			TOKEN_LINE=${TOKEN_LINE#$TOKEN}
 			;;
 	esac