Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Sat, May 10, 2008 at 12:28:00PM +0200, Iustin Pop wrote: > Philipp Reisner wrote: > > Am Sonntag, 4. Mai 2008 02:19:12 schrieb Wolfgang Denk: > > > Hi, > > > > > > I'm trying to run DRBD on top of a LV, and get flooded with above > > > error messages. I know this has been discussed before, see threads > > > starting at > > > http://lists.linbit.com/pipermail/drbd-user/2008-February/008665.html > > > and > > > http://lists.linbit.com/pipermail/drbd-user/2008-February/008519.html > > > > > > When this was discussed in February, it sounded (at least to me) as is > > > a fix was on the way, see > > > http://lists.linbit.com/pipermail/drbd-user/2008-February/008692.html > > > > > > However, even top of tree from the git repo still shows the same > > > behaviour. > > > > > > Am I missing something, or is this usage mode so exotic that nobody > > > cares? > > > > > > > Hi Wolfgang, > > > > That is actually a kernel bug, I think in 2.6.24. Was fixed later, do not > > know by heart with which "sucker" release. I guess it is fixed in 2.6.25. > > > > Starting with 8.0.12 we offer a workaround for this in DRBD (and 8.2.6 > > when I finally find the time to finish it): > > > > Add no-disk-flushes and no-md-flushes to your disk config. > > Because this happens not only with LVM, but with any I/O subsystem that > returns wrong error codes from flushes (e.g. broken scsi drivers or > controller, I think), would it be a sane thing to disable barriers > automatically if there after a certain number of errors? > > (Looking at the barrier flush code I see that only the drbd_receiver.c > has code for auto-disabling in case of EOPNOTSUPP, but drbd_actlog and > drbd_bitmap.c don't; maybe these too should have this). hm? I think we do have a retry-and-disable-barriers in those places too. > The reason I propose this is because with many deployments on different > machines it would be better to let it always enabled at startup and > allow it to autodisable if it see EOPNOTSUPP that is the way we do it. > or too many other errors. and that is what we don't. > And people can't always track latest upstream kernel... if they are stuck with a kernel where DRBD spits out too much noise due to barrier requests throwing IO errors, then they have to disable use of barriers in the drbd config. -- : Lars Ellenberg http://www.linbit.com : : DRBD/HA support and consulting sales at linbit.com : : LINBIT Information Technologies GmbH Tel +43-1-8178292-0 : : Vivenotgasse 48, A-1120 Vienna/Europe Fax +43-1-8178292-82 : __ please don't Cc me, but send to list -- I'm subscribed