On Wed, 2011-09-14 at 23:17 +0200, Hans van Kranenburg wrote: > Hi Ian, > > On 09/11/2011 05:37 PM, Ian Campbell wrote: > > On Sun, 2011-09-11 at 01:18 +0200, Hans van Kranenburg wrote: > >> On 09/08/2011 07:12 PM, Hans van Kranenburg wrote:
> > In the meantime disabling sendpage sounds like the best workaround. > > So, we set the disable_sendpage option, did a domU reboot with drbdadm > down/up of the drbd devices (just to be sure, don't know where/when this > option is read by drbd), and after some days of hitting the disks and > the network with data, no kernel panics happened anymore. Yay! Glad to hear it! > In the post you reference with [1] you write: "I expect that other block > and filesystem users of the network subsystem (e.g. iSCSI) would also > benefit from this functionality since they will suffer from the same > class of issue.". > Part of my work in the near future is doing lenny->squeeze upgrades of > a couple of systems where we use lvm backed block devices for domU's > which are on dm-multipath on iSCSI. > Should I be concerned about the same issues that can happen when using > iSCSI on squeeze? If so, or if unknown, do you recommend specific > (stress)tests that we can do at the test-upgrade environment? The strange thing is that this class of issue has always been present AFAIK, it seems that it just takes a very particular confluence of circumstances (involving heavy load, bad luck etc) before anything goes wrong, although it does seem that if a particular setup is susceptible it will see it quite a lot. DRDB's use of sendpage is pretty recent (I think) which is why you only just started seeing it. I think if you've been using iSCSI up to now without problem I wouldn't expect you to start seeing problems now, although you should obviously keep this issue in mind if you see anything weird. > > [1] http://marc.info/?l=linux-netdev&m=131072801125521&w=2 > > What should be done with this bug report? Should I close it, as there's > a workaround, and there's no simple fix that can be done in squeeze, or > should it be hanging around to be closed when the work on this is done > and included in the kernel? I think there's no harm in keeping it around as a reminder (to me) that something needs to be done. We can close it when the fixed upstream kernel hits Sid. Ian. -- Ian Campbell Heuristics are bug ridden by definition. If they didn't have bugs, then they'd be algorithms. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
