<br><br><div class="gmail_quote">On Thu, Sep 10, 2009 at 11:27 PM, Lars Ellenberg <span dir="ltr"><<a href="mailto:lars.ellenberg@linbit.com">lars.ellenberg@linbit.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Thu, Sep 10, 2009 at 07:11:02PM +0200, Lars Ellenberg wrote:<br>
> On Thu, Sep 10, 2009 at 06:47:24PM +0200, Lars Ellenberg wrote:<br>
> > then something is wrong with your hardware, or your setup.<br>
> > or your kernel.<br>
> > or, of course, maybe only something is wrong with drbd (in your setup on<br>
> > your hardware ;-])<br>
> ><br>
> > care to try<br>
> > no-disk-flushes;<br>
> > no-md-flushes;<br>
> > no-disk-barrier;<br>
> > ?<br>
<br>
<br>
</div>> then add below patch,<br>
<br>
...<br>
<div class="im"><br>
> and the fallback error path in there apparently has been broken for a<br>
> long time :(<br>
<br>
</div>nonsense.<br>
<br>
was a long day ...<br>
<br>
it was right all along.<br>
<br>
this patch just makes it more explicit,<br>
so it won't hurt, anyways.<br>
<br>
but the code as it was before is working correctly.<br>
<br>
so I guess you are back to those options below ;)<br>
<div class="im"><br>
> > if that does not help:<br>
> > 8.3.2?<br>
> > 8.3.3rc2?<br>
> > various other drbd versions? kernels?<br>
> > different lower level device? (not cciss? other cciss drive/partition?)<br>
> > etc.<br>
> ><br>
> > if all else fails: contact linbit, we do sell support.<br>
> ><br>
> > we even sell "drbd health checks", which somewhat boils down to a<br>
> > one-time engagement - though for those you may need to wait for a<br>
> > suitable (for linbit) time-slot.</div><br></blockquote></div><br>No problem!<br><br>
I have been testing for about 2 months with 8.2, 8.3.2 and 8.3.3rc1 in this hw config without this kind of problem.<br>
The OS is F11 and the kernel was always based on 2.6.29.<br>
The main thing changed few days ago was F11 passing to kernel 2.6.30 and me to update it (but I still have the 2.6.29 based one).<br>
So one of the causes could probably be this.<br>
<br>
I can test several possibilities tomorrow @office.<br>
What order do you prefer, considering the variables outlined:<br>
<br>
- kernel 2.6.29 vs 2.6.30<br>
- drdb 8.3.3rc1 vs 8.3.3rc2<br>
- applying the patch proposed (step no more needed)<br>
- changing what suggested in drbd.conf<br>
<br>
In this state, would a "service drbd stop" of the diskless peer succeed? And the other one? Would I come back to the same diskless state after reboot/drbd reload? <br><br>
If you give me some ordered steps I'm available to follow them in order to provide the more useful information you would need.<br><br>