From owner-freebsd-fs@FreeBSD.ORG Wed Feb 28 18:32:23 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 A2BB616A400 for ; Wed, 28 Feb 2007 18:32:23 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7775713C4A5 for ; Wed, 28 Feb 2007 18:32:23 +0000 (UTC) (envelope-from anderson@freebsd.org) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.8/8.13.8) with ESMTP id l1SIWMFT045343; Wed, 28 Feb 2007 12:32:22 -0600 (CST) (envelope-from anderson@freebsd.org) Message-ID: <45E5CABA.8070105@freebsd.org> Date: Wed, 28 Feb 2007 12:32:26 -0600 From: Eric Anderson User-Agent: Thunderbird 1.5.0.9 (X11/20070204) MIME-Version: 1.0 To: Jason Arnaute References: <629647.7934.qm@web51004.mail.yahoo.com> In-Reply-To: <629647.7934.qm@web51004.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.4/2679/Wed Feb 28 05:58:10 2007 on mh1.centtech.com X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=8.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.6 X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on mh1.centtech.com Cc: freebsd-fs@freebsd.org 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: Wed, 28 Feb 2007 18:32:23 -0000 On 02/28/07 10:18, Jason Arnaute wrote: > --- Eric Anderson wrote: > > >> 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. > > > Thanks - this may be the most useful way to do this. > > But you're right - it's not exactly what I want ... > provided that the critical filesystems are already > clean (all I have are /, /var, and (bulk_data)) I wish > it would just come up and say: > > "if they're clean, mount them and be happy. If > they're not, just _don't mount them_. Just don't do > anything. You've got your / and /var, so just be > happy and wait for someone to manually bring up > (bulk_data)" > > The reason this would work is that / and /var _always_ > get foreground fsck'd before the system can go > multi-user anyway ... so they are always safe ... You could work up a patch to the rc* stuff (plus maybe a few other tools) that would allow a new FSTAB_** define that means just that. Eric