Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Thu, Sep 10, 2009 at 11:27 PM, Lars Ellenberg <lars.ellenberg at linbit.com>wrote: > On Thu, Sep 10, 2009 at 07:11:02PM +0200, Lars Ellenberg wrote: > > On Thu, Sep 10, 2009 at 06:47:24PM +0200, Lars Ellenberg wrote: > > > then something is wrong with your hardware, or your setup. > > > or your kernel. > > > or, of course, maybe only something is wrong with drbd (in your setup > on > > > your hardware ;-]) > > > > > > care to try > > > no-disk-flushes; > > > no-md-flushes; > > > no-disk-barrier; > > > ? > > > > then add below patch, > > ... > > > and the fallback error path in there apparently has been broken for a > > long time :( > > nonsense. > > was a long day ... > > it was right all along. > > this patch just makes it more explicit, > so it won't hurt, anyways. > > but the code as it was before is working correctly. > > so I guess you are back to those options below ;) > > > > if that does not help: > > > 8.3.2? > > > 8.3.3rc2? > > > various other drbd versions? kernels? > > > different lower level device? (not cciss? other cciss drive/partition?) > > > etc. > > > > > > if all else fails: contact linbit, we do sell support. > > > > > > we even sell "drbd health checks", which somewhat boils down to a > > > one-time engagement - though for those you may need to wait for a > > > suitable (for linbit) time-slot. > > No problem! 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. The OS is F11 and the kernel was always based on 2.6.29. 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). So one of the causes could probably be this. I can test several possibilities tomorrow @office. What order do you prefer, considering the variables outlined: - kernel 2.6.29 vs 2.6.30 - drdb 8.3.3rc1 vs 8.3.3rc2 - applying the patch proposed (step no more needed) - changing what suggested in drbd.conf 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? If you give me some ordered steps I'm available to follow them in order to provide the more useful information you would need. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20090910/4b1cab3a/attachment.htm>