From owner-freebsd-current@FreeBSD.ORG Sat Oct 16 03:28:28 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 6881616A4CE; Sat, 16 Oct 2004 03:28:28 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05B7143D3F; Sat, 16 Oct 2004 03:28:28 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.254.200] ([192.168.254.200]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i9G3SPYS027729; Fri, 15 Oct 2004 21:28:25 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <41709506.9030100@freebsd.org> Date: Fri, 15 Oct 2004 21:27:02 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040929 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrey Chernov 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> In-Reply-To: <20041016024840.GA50424@nagual.pp.ru> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: David Schultz 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 03:28:28 -0000 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. Scott