From owner-freebsd-current Wed Apr 5 11:42:46 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 737FA37B9E4; Wed, 5 Apr 2000 11:42:41 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA79600; Wed, 5 Apr 2000 11:42:40 -0700 (PDT) (envelope-from dillon) Date: Wed, 5 Apr 2000 11:42:40 -0700 (PDT) From: Matthew Dillon Message-Id: <200004051842.LAA79600@apollo.backplane.com> To: "Jonathan M. Bresler" Cc: brdean@unx.sas.com, grog@lemis.com, phk@critter.freebsd.dk, blk@skynet.be, asmodai@wxs.nl, current@FreeBSD.ORG Subject: Vinum breakage Summary (was Re: Vinum breakage) References: <20000405170350.103FC37BBA8@hub.freebsd.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Matt, : help me understand your patch. this is how i read it at this :time: : : :Matt has just made available an early patch that corrects the vinum :panic. is this the same vinum panic that people are claiming phk :created with the bio/buf changes? i dont know the vinum code. i dont :know the bio/buf code. i do see that all the code changes are to :vinum source files. none of the changes reference the buf/bio parts :for the kernel. : :the patch is against 4.0, code unaffected by phk's changes. :the revision levels are those indicated in Matt's patch and those I :recevied via CVSup last night. There is a lot of confusion here, which I will straighten out: * 3/20 - phk makes his first buffer cache commit, adding b_iocmd. This breaks vinum, but it takes a while for people to realize it. (see 1.46 sys/dev/vinum/vinumrequest.c and other files) This commit is made into -current. -stable is not effected * 3/26 - alfred fixes phk's type-o that broke vinum (1.47 vinumrequest.c, and other files). (3/26 == last week). * During the last week, at aroudn the same time, a panic was traced definitively to vinum. On saturday it was traced to the raid5 code. Some of the people using vinum, including Greg, are using it under -current. * Phk begins making more radical commits (to -current) on sunday. * Confusion reigns. I don't think the later commits broke vinum again, but at this point there were a number of people focused on vinum and having the buffer cache ripped out from under them might have resulted in false positives due to people using vinum as a kld rather then building it into the kernel. I believe there was a message or two in this regard that turned out to be a false positive. * Greg's test machine was running -current. Greg is dead in the water at this point (i.e. he would need to retool to -stable), and complains mightily (and appropriately, I believe). Despites the truth that it would be better to track the vinum bug down in -stable, the fact remains that many people are using -current. * I start complaining about the lack of discussion, review, notification, or documentation prior to phk's commits. * Phk is referenced by Brad as breaking vinum in 4.0, which is incorrect (message-id ), on 4/4, and Brad retracts this later when the mistake is realized, also on 4/4. (more confusion added to the mix). * I spend five or six hours settings vinum up on my -stable test box to try to reproduce and fix the panic on monday. * I come up with a patch, which Greg is now reviewing & using as a basis for the 'real' fix. This patch fixes a bug in vinum -- we knew there was one (on saturday, see above). The only known bug introduced by phk's commit (so far) was fixed by Alfred on 3/26. This panic is not related to phk's commits. My patch is relative to 4.0. * It is currently unknown whether further breakage in -current exists due to phk's changes. I don't think we'll know whether there are further problems until the currently known bug fix is committed and we see where we stand. * I also do not know if Greg has successfully retooled his test box to run -stable. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message