[DRBD-user] same(?) drbd/xen kernel panic problem

[Tom Brown]

>>
>>  I had no luck with changing the scatter/gather and checksum parameters,
>>  for me it was code-change or protocol A.
>>
>>  And replicating the problem is simple enough if you have some test
>>  machines you can work with... just ifdown the interface on the secondary,
>>  type sync in the xen guest (domU) and wait about 30 seconds.
>> 
> Tom,
> thanks for clarification. AFAIK protocol A cannot be used with 
> "allow-two-primaries" option, I have to sacrifice live migration.

I prefer to put the storage on the network, which is why I'm not longer 
actually hitting this bug, and I also don't need dual primaries... but 
that's neither here nor there.

> Perhaps I am missing something [again] but I haven't seen in DRBD mailing 
> list that 1 line code change you mentioned.
>
> Regards,
> Ivars

quoting from:
http://article.gmane.org/gmane.comp.linux.drbd/17684

diff --git a/drbd/drbd_main.c b/drbd/drbd_main.c
index 6edcb11..dce18ee 100644
--- a/drbd/drbd_main.c
+++ b/drbd/drbd_main.c
@@ -2122,7 +2122,7 @@ int _drbd_send_page(struct drbd_conf *mdev, struct 
page *page,
  	 * doh. it triggered. so XFS _IS_ really kaputt ...
  	 * oh well...
  	 */
-	if ((page_count(page) < 1) || PageSlab(page)) {
+	if (1 || (page_count(page) < 1) || PageSlab(page)) {
  		/* e.g. XFS meta- & log-data is in slab pages, which have 
a
  		 * page_count of 0 and/or have PageSlab() set...
  		 */



which is what I was describing earlier in that thread when I said "If you 
really want protocol C, the code change is pretty simple, as there already 
is a "_drbd_no_send_page()" function, you just want to change the logic so 
it always goes down that path (currently it's a special case exception)."

Note that it's hard thread to find on gmane.org as it dates back to 
february and is currently on page 6 :(

-Tom