From owner-freebsd-current@FreeBSD.ORG Sat Oct 16 04:47:30 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D985516A4CE; Sat, 16 Oct 2004 04:47:30 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B30443D49; Sat, 16 Oct 2004 04:47:30 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.1/8.12.10) with ESMTP id i9G4lWg1073620; Sat, 16 Oct 2004 00:47:32 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.1/8.12.10/Submit) id i9G4lVI9073619; Sat, 16 Oct 2004 00:47:31 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Sat, 16 Oct 2004 00:47:31 -0400 From: David Schultz To: Scott Long Message-ID: <20041016044731.GA73571@VARK.MIT.EDU> Mail-Followup-To: Scott Long , Andrey Chernov , current@FreeBSD.ORG, pjd@FreeBSD.ORG References: <20041015075641.GA6820@nagual.pp.ru> <20041015171144.GA69709@VARK.MIT.EDU> <20041015171700.GA74901@nagual.pp.ru> <20041016021131.GA72979@VARK.MIT.EDU> <417089E6.8030105@freebsd.org> <20041016024840.GA50424@nagual.pp.ru> <41709506.9030100@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41709506.9030100@freebsd.org> cc: Andrey Chernov cc: pjd@FreeBSD.ORG cc: current@FreeBSD.ORG Subject: Re: Stable panic on shutdown: swapoff: failed to locate N swap blocks X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2004 04:47:31 -0000 On Fri, Oct 15, 2004, Scott Long wrote: > Andrey Chernov wrote: > >On Fri, Oct 15, 2004 at 08:39:34PM -0600, Scott Long wrote: > > > >>FWIW, I think that doing a swapoff in the shutdown path is just asking > >>for trouble. Fixing whatever bug this is would of course be nice, but > >>the need for swapoff here is a hack and only opens up up to problems. > > > > > >I agree. It looks like sort of race happens. Application (cvsupd) can be > >killed, but its inodes activity delayed by softupdates a bit more (just > >raw guess). I see no useful purpose to call swapoff(8) at shutdown stage, > >correct me, if I am not right. > > > > The swapoff hack is needed so that the swapper will close the swap > device and remove the reference on the gmirror instance, which in turn > allows gmirror to know that it can close itself down. Pawel has a patch that moves the swapoff() later in the shutdown sequence, after all user processes have been killed. It should make swapoff() basically a no-op / sanity check, since nothing should actually be paged out at that point.