Looking for a graceful way to disable BG fsck ?

Brooks Davis brooks at freebsd.org
Fri Mar 2 20:24:09 UTC 2007


On Fri, Mar 02, 2007 at 02:32:48PM -0500, Adam Martin wrote:
> All,
> 
> On Feb 28, 2007, at 8:21 AM, Eric Anderson wrote:
> 
> >On 02/28/07 07:08, R. B. Riddick wrote:
> >>--- Jason Arnaute <non_secure at yahoo.com> 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.)

The following patch allows you to delay the bgfsck indefinitly and then
run it later by running with bgfsck with forcestart.  I've suppressed
all output in the forcestart case to allow it to be run out of cron.  It
seems to be working for me.

-- Brooks

Index: etc/rc.d/bgfsck
===================================================================
RCS file: /usr/cvs/src/etc/rc.d/bgfsck,v
retrieving revision 1.7
diff -u -p -r1.7 bgfsck
--- etc/rc.d/bgfsck	22 Jul 2005 00:57:37 -0000	1.7
+++ etc/rc.d/bgfsck	12 Feb 2007 19:53:12 -0000
@@ -16,11 +16,23 @@ stop_cmd=":"
 
 bgfsck_start ()
 {
+	if [ -z "${rc_force}" ]; then
+		background_fsck_delay=${background_fsck_delay:=0}
+	else
+		background_fsck_delay=0
+	fi
+	if [ ${background_fsck_delay} -lt 0 ]; then
+		echo "Background file system checks delayed indefinitly"
+		return 0
+	fi
+
 	bgfsck_msg='Starting background file system checks'
-	if [ ${background_fsck_delay:=0} -gt 0 ]; then
+	if [ "${background_fsck_delay}" -gt 0 ]; then
 		bgfsck_msg="${bgfsck_msg} in ${background_fsck_delay} seconds"
 	fi
-	echo "${bgfsck_msg}."
+	if [ -z "${rc_force}" ]; then
+		echo "${bgfsck_msg}."
+	fi
 
 	(sleep ${background_fsck_delay}; nice -4 fsck -B -p) 2>&1 | \
 	    logger -p daemon.notice -t fsck &
Index: share/man/man5/rc.conf.5
===================================================================
RCS file: /usr/cvs/src/share/man/man5/rc.conf.5,v
retrieving revision 1.314
diff -u -p -r1.314 rc.conf.5
--- share/man/man5/rc.conf.5	24 Jan 2007 09:22:56 -0000	1.314
+++ share/man/man5/rc.conf.5	2 Mar 2007 20:19:31 -0000
@@ -1359,6 +1359,15 @@ The amount of time in seconds to sleep b
 It defaults to sixty seconds to allow large applications such as
 the X server to start before disk I/O bandwidth is monopolized by
 .Xr fsck 8 .
+If set to a negative number, the background file system check will be
+delayed indefinitely to allow the administrator to run it at a more
+convenient time.
+For example it may be run from cron by adding a line like
+.Pp
+.Dl 0 4 * * * root /etc/rc.d/bgfsck forcestart
+.Pp
+to
+.Pa /etc/crontab .
 .It Va netfs_types
 .Pq Vt str
 List of file system types that are network-based.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20070302/710a17b4/attachment.pgp


More information about the freebsd-fs mailing list