Date: Fri, 2 Mar 2007 14:32:48 -0500 From: Adam Martin <adamartin@FreeBSD.org> To: freebsd-fs@freebsd.org Cc: ADAM David Alan Martin <adam@fsl.cs.sunysb.edu> Subject: Re: Looking for a graceful way to disable BG fsck ? Message-ID: <206E31A0-C35D-462E-9C31-65ECFCDFC16B@FreeBSD.org> In-Reply-To: <45E581DF.4070706@freebsd.org> References: <822542.17658.qm@web30312.mail.mud.yahoo.com> <45E581DF.4070706@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?206E31A0-C35D-462E-9C31-65ECFCDFC16B>