Looking for a graceful way to disable BG fsck ?

[Adam Martin]

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.)

	That's just my 0.02USD.

--
ADAM David Alan Martin