From owner-freebsd-fs@FreeBSD.ORG Fri Mar 2 20:00:48 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 99B0816A402 for ; Fri, 2 Mar 2007 20:00:48 +0000 (UTC) (envelope-from adamlsd@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.226]) by mx1.freebsd.org (Postfix) with ESMTP id 5792113C4A3 for ; Fri, 2 Mar 2007 20:00:48 +0000 (UTC) (envelope-from adamlsd@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so805898wxc for ; Fri, 02 Mar 2007 12:00:48 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer:sender; b=flou1yJ/cZyxwJZtIpGv5xKMg/2HcPoqM3xKOkR2qpWVm9Pg0q02EfNXApGEXGRSTxL87e+Loag+l3x5+z1F6h73dZg5um/ZEF9UnIxY7kdoN1PWfwk9nNXlKucv7gX5RpdkLLYDZ9hXEDgzTioY1LuXY1rfmMdNmpuE/0bXoF0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer:sender; b=tvwRypNO/dcy9CjD5+d4JWpaNKIaclwzoGk+hJvm0IcTjpiCe32XwL8Aj4m8DQKr1TqMNq034TTBtfkdIWlvh2gFbGg6B5HSWrIxrmAF6msqySjIzrajNay0IVlTSVlkYCPlnUz6NQbxLUzTfse2q7wIKWNBIR3ua4jARpwE1Sg= Received: by 10.90.71.12 with SMTP id t12mr3226364aga.1172863971322; Fri, 02 Mar 2007 11:32:51 -0800 (PST) Received: from ?129.49.5.118? ( [129.49.5.118]) by mx.google.com with ESMTP id 34sm4663016wra.2007.03.02.11.32.50; Fri, 02 Mar 2007 11:32:50 -0800 (PST) In-Reply-To: <45E581DF.4070706@freebsd.org> References: <822542.17658.qm@web30312.mail.mud.yahoo.com> <45E581DF.4070706@freebsd.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <206E31A0-C35D-462E-9C31-65ECFCDFC16B@FreeBSD.org> Content-Transfer-Encoding: 7bit From: Adam Martin Date: Fri, 2 Mar 2007 14:32:48 -0500 To: freebsd-fs@freebsd.org X-Mailer: Apple Mail (2.752.2) Sender: Adam Martin Cc: ADAM David Alan Martin Subject: Re: Looking for a graceful way to disable BG fsck ? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2007 20:00:48 -0000 All, On Feb 28, 2007, at 8:21 AM, Eric Anderson wrote: > On 02/28/07 07:08, R. B. Riddick wrote: >> --- Jason Arnaute wrote: >>> Is there any nice, elegant way to tell my system: >>> >>> "If everything is clean, then mount it all up and go. But if a >>> non-root filesystem is not clean, just skip >>> it altogether and boot up into multiuser mode and I >>> will log in and fsck it manually. But under no >>> circumstances will you BG fsck anything." >>> >>> Any way to do that ? > > How about setting something like this: > background_fsck_delay="864000" > > in /etc/rc.conf? That would make bg fsck wait 10 days before > running. That will still mount the disks rw though, which is > probably not what you really want. I do a large amount of kernel modifications (I'm developing a new filesystem). Resultingly, every few hours, I'm bound to panic the kernel, from some stupid mistake I'll make. I set my background_fsck_delay to an appropriately large value, myself. It's worked well for me, on the test box that I have. (In my case, about 6000 seconds has been the magic value. If the system's up for more than 2 hours, it's not likely to go down any time soon -- I've likely wrapped up for the day. So the discs can now start checking.) Incidentally, the background_fsck_delay is just used as an argument to sleep(1). You could set it to a value on the order of months or years, and just kill the sleep launched by /etc/rc.d/bgfsck, when you want to force the discs to fsck. (Otherwise the discs will not fsck.) While waiting for this bgfsck-sleep, it seems safe, in my experience, to force a bgfsck on any mounted filesystem. (/sbin/fsck isn't launched, it's waiting on sleep(1) to finish, so I'd wager it's totally safe. I've never had problems with double fscking a filesystem. But I never had 2 concurrent bgfscks run on a filesystem...) As I understand it, it can be wise to have the bgfsck run at some point, however. About a year ago, I had a failing disc controller, which kept panicking the kernel, and I got munged data on the drive (particularly in the ufs data structures). Even after replacing the controller, the resultant fs-corruption kept panicking the kernel in the vfs. When in single-user, I forced a fsck on the filesystems, in foreground, and that solved everything. Luckily I didn't lose any important data (most of the time the vfs would panic the kernel on file creation.) So I would suggest that you not glaze over the need to fsck. (You may want to have bgfsck use atq, to schedule some form of fsck at a specific time when you expect low system usage.) That's just my 0.02USD. -- ADAM David Alan Martin