From owner-freebsd-rc@FreeBSD.ORG Wed Jun 9 05:30:04 2010 Return-Path: Delivered-To: freebsd-rc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E5B91065670 for ; Wed, 9 Jun 2010 05:30:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1CDEC8FC18 for ; Wed, 9 Jun 2010 05:30:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o595U3Dn041762 for ; Wed, 9 Jun 2010 05:30:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o595U30p041759; Wed, 9 Jun 2010 05:30:03 GMT (envelope-from gnats) Date: Wed, 9 Jun 2010 05:30:03 GMT Message-Id: <201006090530.o595U30p041759@freefall.freebsd.org> To: freebsd-rc@FreeBSD.org From: Brian Somers Cc: Subject: Re: misc/147685: new feature for /etc/rc.d/fsck X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Brian Somers List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 05:30:04 -0000 The following reply was made to PR conf/147685; it has been noted by GNATS. From: Brian Somers To: Alex Keda Cc: freebsd-gnats-submit@freebsd.org Subject: Re: misc/147685: new feature for /etc/rc.d/fsck Date: Tue, 8 Jun 2010 22:12:05 -0700 On Tue, 8 Jun 2010 10:48:09 GMT Alex Keda wrote: > > >Number: 147685 > >Category: misc > >Synopsis: new feature for /etc/rc.d/fsck > >Confidential: no > >Severity: non-critical > >Priority: low > >Responsible: freebsd-bugs > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: update > >Submitter-Id: current-users > >Arrival-Date: Tue Jun 08 10:50:01 UTC 2010 > >Closed-Date: > >Last-Modified: > >Originator: Alex Keda > >Release: 9.0-CURRENT > >Organization: > USSR > >Environment: > FreeBSD lissyara.moskb.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r208900: Tue Jun 8 08:46:18 MSD 2010 root@lissyara.moskb.local:/usr/obj/usr/src/sys/GENERIC amd64 > >Description: > We have many servers located in datacenters. These difficult physical access. After several years of work, unexpected reboot (power problems, panic, ....) on the file system with errors. Not all file system may check and fix remotely - /, / usr can not unmount at work. > > This patch allows you to schedule a scan file systems at boot time, before they are mounted. > >How-To-Repeat: > > >Fix: > see attached patch > > Patch attached with submission follows: > > --- /tmp/fsck.orig 2010-06-08 14:17:59.000000000 +0400 > +++ /etc/rc.d/fsck 2010-06-08 14:18:24.000000000 +0400 > @@ -27,7 +27,16 @@ > if checkyesno background_fsck; then > fsck -F -p > else > - fsck -p > + if checkyesno force_fsck; then > + echo "Force fsck enabled" > + for filesystem in ${force_fsck_list} > + do > + echo "Force check $filesystem" > + fsck -y $filesystem > + done > + else > + fsck -p > + fi > fi > > case $? in > --- /tmp/rc.conf 2010-06-08 14:36:52.000000000 +0400 > +++ /etc/defaults/rc.conf 2010-06-08 14:38:55.000000000 +0400 > @@ -87,6 +87,9 @@ > fsck_y_flags="" # Additional flags for fsck -y > background_fsck="YES" # Attempt to run fsck in the background where possible. > background_fsck_delay="60" # Time to wait (seconds) before starting the fsck. > +force_fsck="NO" # force check filesystems on startup > +force_fsck_list="" # list file systems for force check on startup > +#force_fsck_list="/ /usr /var" > netfs_types="nfs:NFS nfs4:NFS4 smbfs:SMB portalfs:PORTAL nwfs:NWFS" # Net filesystems. > extra_netfs_types="NO" # List of network extra filesystem types for delayed > # mount at startup (or NO). > > > >Release-Note: > >Audit-Trail: > >Unformatted: This patch will avoid running fsck -p, so filesystems not in $force_fsck_list will miss out. Personally I'd prefer to see a feature like this integrated with nextboot(8) and handled on a once-only basis before the fsck -p. Although nextboot currently only handles kernel boot info, it seems the right place for this feature. nextboot -c / -c /usr would force fsck of both / and /usr, then remove the configuration so that a subsequent reboot would not force the same fsck again. What do you think? -- Brian Somers Don't _EVER_ lose your sense of humour !