Date: Tue, 10 Mar 2009 14:07:43 -0400 From: David Schultz <das@FreeBSD.ORG> To: Gavin Atkinson <ga9@york.ac.uk> Cc: svn-src-head@FreeBSD.ORG, Guido van Rooij <guido@FreeBSD.ORG>, src-committers@FreeBSD.ORG, svn-src-all@FreeBSD.ORG Subject: Re: svn commit: r189624 - head/etc/rc.d Message-ID: <20090310180743.GA72342@zim.MIT.EDU> In-Reply-To: <1236699209.62820.32.camel@buffy.york.ac.uk> References: <200903101519.n2AFJovP065743@svn.freebsd.org> <1236699209.62820.32.camel@buffy.york.ac.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 10, 2009, Gavin Atkinson wrote: > On Tue, 2009-03-10 at 15:19 +0000, Guido van Rooij wrote: > > Author: guido > > Date: Tue Mar 10 15:19:49 2009 > > New Revision: 189624 > > URL: http://svn.freebsd.org/changeset/base/189624 > > > > Log: > > When swap resides on a mirror and it is not stopped, the mirror > > is degraded upon the next reboot and will have to be rebuild. > > Thus call swapoff when rebooting (read: when stopping swap1) > > Is this due to a bug/feature of gmirror? A long time ago, swapoff used > to be run on shutdown, but it was removed by pjd@ in src/etc/rc.d/swap1 > version 1.9 with the following commit message: > > | Stop method for swap1 script was introduced, because gmirror needed > | it. Now gmirror use shutdown hooks to mark mirrors as clean on > | shutdown, so this is not needed anymore. > > I'm not saying it's not needed, just intrigued why it is now needed > again when it never used to be? > > FWIW, I seem to remember that one of the reasons it was removed was that > turning swap off created the possibility that lots of things would be > paged back into RAM, which a) could take a long time, and b) fail if > there was insufficient RAM. Ideally it should be done only when (if?) needed, and as late as possible in the shutdown process. For one, it's rather pointless to swap in all the pages for applications that will only be killed anyway. For two, swapoff() was designed as an infrequent administrative operation; it's not robust against I/O errors, and it doesn't do clustering or otherwise attempts to be efficient.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090310180743.GA72342>