From owner-freebsd-current@FreeBSD.ORG Sat May 15 22:43:42 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 5C3E216A4CE for ; Sat, 15 May 2004 22:43:42 -0700 (PDT) Received: from us18.unix.fas.harvard.edu (us18.unix.fas.harvard.edu [140.247.35.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B22843D2D for ; Sat, 15 May 2004 22:43:41 -0700 (PDT) (envelope-from hamburg@fas.harvard.edu) Received: from [140.247.133.37] (roam133-37.student.harvard.edu [140.247.133.37])i4G5heNv031316 for ; Sun, 16 May 2004 01:43:40 -0400 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <20040515233728.Q30269@ganymede.hub.org> References: <20040515220258.H920@ganymede.hub.org> <20040515233728.Q30269@ganymede.hub.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Michael Hamburg Date: Sun, 16 May 2004 01:43:37 -0400 To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.613) Subject: Re: fsck in -current 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: Sun, 16 May 2004 05:43:42 -0000 On May 15, 2004, at 10:41 PM, Marc G. Fournier wrote: > On Sat, 15 May 2004, Michael Hamburg wrote: > >> On May 15, 2004, at 9:08 PM, Marc G. Fournier wrote: >> >>> >>> I'm seriously considering putting 5.x onto my next server, to take >>> advantage of, if nothing else, the reduction in the GIANT LOCK >>> reliance >>> ... one "concern" I have is how fsck works in 5.x ... >>> >>> Right now, on 4.x, I have an fsck running that has been going for >>> ~3hrs >>> now: >>> >>> # date; ps aux | grep fsck >>> Sat May 15 22:04:00 ADT 2004 >>> root 40 99.0 4.5 185756 185796 p0 R+ 6:55PM 164:01.60 fsck >>> -y >>> /dev/da0s1h >>> >>> and is in Phase 4 ... >>> >>> In 5.x, if I'm not mistaken, fsck's are backgrounded on reboot, so >>> that >>> the system comes up faster ... but: >>> >>> a. wouldn't that slow down the fsck itself, since all the processes >>> on >>> the >>> machine would be using CPU/memory? >> >> Yes. You can probably renice it or something, though, and it wouldn't >> take that much longer. >> >> Furthermore, if I recall correctly, it doesn't check as much after a >> crash when soft-updates are enabled. See below. >> >>> b. how long could fsck run in the background safely ... like, if I >>> rebooted a machine, fsck backgrounded and then all the processes >>> started up, is there a risk involved? >>> >> >> No, fsck should be able to run in the background indefinitely with >> basically no risk, so long as you have free space on your disk. The >> way that the latest fsck works is that it snapshots the drive, and >> then >> checks the snapshot; the only type of error that it's expecting to >> find >> is files which have been deleted but whose space has not been >> reclaimed. This space can be recovered without confusing running >> processes. > > 'k ... fsck just started spewing messages to the screen, which is nice > cause now I know its actually doing something: > > ZERO LENGTH DIR I=5159669 OWNER=root MODE=40755 > SIZE=0 MTIME=May 10 17:32 2004 > CLEAR? yes > > now, the ZERO LENGTH DIR is a result of using unionfs ... but would > that > cause any issues with the snapshotting? like, how much 'free space' > would > you need, and what happens ifyou don't have enough? :( > I don't know about ZERO LENGTH DIRs... I've never had to deal with anything terribly interesting in an interactive fsck. You don't need much space unless you have high turnover -- the default extra space in FFS that you can't allocate anyway should be plenty, but as far as I can tell, if you do run out of space, Very Bad Things Happen (tm). Just what those Very Bad Things are probably depends on the release. Mike