From owner-freebsd-stable@FreeBSD.ORG Sat Jul 16 14:08:50 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B2B616A41F for ; Sat, 16 Jul 2005 14:08:50 +0000 (GMT) (envelope-from bv@bilver.wjv.com) Received: from wjv.com (fl-65-40-24-38.sta.sprint-hsd.net [65.40.24.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5583B43D5D for ; Sat, 16 Jul 2005 14:08:48 +0000 (GMT) (envelope-from bv@bilver.wjv.com) Received: from bilver.wjv.com (localhost.wjv.com [127.0.0.1]) by wjv.com (8.12.11/8.13.1) with ESMTP id j6GE8kCb007291 for ; Sat, 16 Jul 2005 10:08:46 -0400 (EDT) (envelope-from bv@bilver.wjv.com) Received: (from bv@localhost) by bilver.wjv.com (8.12.11/8.13.1/Submit) id j6GE8j9i007290 for freebsd-stable@freebsd.org; Sat, 16 Jul 2005 10:08:45 -0400 (EDT) (envelope-from bv) Date: Sat, 16 Jul 2005 10:08:35 -0400 From: Bill Vermillion To: freebsd-stable@freebsd.org Message-ID: <20050716140835.GE6192@wjv.com> References: <20050715221356.5A5B916A42D@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050715221356.5A5B916A42D@hub.freebsd.org> Organization: W.J.Vermillion / Orlando - Winter Park ReplyTo: bv@wjv.com User-Agent: Mutt/1.5.6i X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on bilver.wjv.com Subject: Re: dangerous situation with shutdown process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bv@wjv.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2005 14:08:50 -0000 Somewhere around Fri, Jul 15, 2005 at 22:13 , the world stopped and listened as freebsd-stable-request@freebsd.org graced us with this profound tidbit of wisdom that would fulfill the enjoyment of future generations: > Date: Fri, 15 Jul 2005 18:22:14 +0200 > From: Matthias Buelow > Subject: Re: dangerous situation with shutdown process > To: Bill Vermillion > Cc: freebsd-stable@freebsd.org > Message-ID: <20050715162214.GA665@drjekyll.mkbuelow.net> > Content-Type: text/plain; charset=us-ascii > Bill Vermillion wrote: > >Copying very large files and then shutting down I hope is not a > >normal procecure for you. softupdates sometimes do take a long > >time when you are removing/copying very large files. > >Others have suggested different time-outs but you'd have to figure > >out the largest size you may every encounter and set things for > >that, which is not going to help for everyday operation. > >I've watched the amount of disk space increase slowly by performing > >'df' and it can take a long time - up to a minute on some extremely > >large partitions I was cleaning. > >One way to force everything to be written I've found [by > >observation only] is to perform an fsck on that file system. > >If you only do huge copies and immediate shutdowns rarely, then > >maybe it's just a good idea to remember how softupdates work, and > >then fsck, then shutdown. > >I'm always against changing default operations from typical > >operations to extremes. > Sorry folks, have I somehow dropped into a parallel universe, > or is there some serious misunderstanding going on? > To the OP: There is no "sync" process that is being killed by > shutdown. The kernel writes out all dirty buffers as part of its > shutdown procedure. I was under the impression that there was a problem, that's why I wrote my reply. > Bill, as I get it from what you wrote, correct me if I'm wrong, > you assume that: > 1. unmount doesn't wait for all dirty data being committed > to disk before somehow removing the filesystem, That's what the OP seemed to indicate. > 2. fsck on a live filesystem will somehow speed things up. Actually an fsck on a live filesystem will force the softupdates to complete more quickly - that is from observation - and when I've deleted extremly large directories - usually /usr/src and /usr/obj. It only speeds up flushing the blocks to disk. > For 1., this is surely not the case, the same as with shutdown, > the kernel of course writes (drive errors notwithstanding) > all modified buffers and updates all on-disk structures before > marking the fs clean, and > for 2., you should never fsck a mounted filesystem. Besides, > it is completely unnecessary. You can fsck a mounted file system and fsck will run in read-only mode. That way you can check for problems, and if there is something wrong you can shutdown and restart. FreeBSD will NOT run fsck in anything other than READ ONLY when the file system is mounted And in the old days when drives were smaller and slower and perfomance needed to be maximized, from about Verision III through System V you could run fsck -S from cron!! The -S flag was interesting in that it would actually re-write the freelist IF AND ONLY IF there was no corruption on the drive. Since blocks on those systems were used in the revers order they were released, running fsck -S sorted the freelist in ascending order and thus helped to elminate fragmentation. This was particularly important on the S51 file systems - as it was before the SysV's adoptedf variants of the FFS system that came from BSD. > If the OP has encountered any data corruption, this is due to > an unclean shutdown because of disk errors or a kernel bug, > and not because of "timeouts" that are too short or something > like that. It would have been nice to see his actual errors. Bill -- Bill Vermillion - bv @ wjv . com