Date: Sat, 16 Oct 2004 00:47:31 -0400 From: David Schultz <das@FreeBSD.ORG> To: Scott Long <scottl@FreeBSD.ORG> Cc: current@FreeBSD.ORG Subject: Re: Stable panic on shutdown: swapoff: failed to locate N swap blocks Message-ID: <20041016044731.GA73571@VARK.MIT.EDU> In-Reply-To: <41709506.9030100@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041016044731.GA73571>