From owner-freebsd-stable@FreeBSD.ORG Fri Jul 15 21:55:54 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 4151016A41C for ; Fri, 15 Jul 2005 21:55:54 +0000 (GMT) (envelope-from mkb@mkbuelow.net) Received: from luzifer.incubus.de (incubus.de [80.237.207.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0BE843D48 for ; Fri, 15 Jul 2005 21:55:53 +0000 (GMT) (envelope-from mkb@mkbuelow.net) Received: from drjekyll.mkbuelow.net (p54AA8680.dip0.t-ipconnect.de [84.170.134.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by luzifer.incubus.de (Postfix) with ESMTP id 93A7E32A48; Fri, 15 Jul 2005 23:58:45 +0200 (CEST) Received: from drjekyll.mkbuelow.net (mkb@localhost.mkbuelow.net [127.0.0.1]) by drjekyll.mkbuelow.net (8.13.3/8.13.3) with ESMTP id j6FLu4C5015051; Fri, 15 Jul 2005 23:56:05 +0200 (CEST) (envelope-from mkb@drjekyll.mkbuelow.net) Message-Id: <200507152156.j6FLu4C5015051@drjekyll.mkbuelow.net> From: Matthias Buelow To: "Kevin Oberman" In-Reply-To: Message from "Kevin Oberman" of "Fri, 15 Jul 2005 14:03:19 PDT." <20050715210320.01E215D07@ptavv.es.net> X-Mailer: MH-E 7.84; nmh 1.0.4; XEmacs 21.4 (patch 17) Date: Fri, 15 Jul 2005 23:56:04 +0200 Sender: mkb@mkbuelow.net Cc: freebsd-stable@freebsd.org Subject: Re: dangerous situation with shutdown process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2005 21:55:54 -0000 "Kevin Oberman" writes: >I believe that the Windows solution to this problem is to put a really, >really long delay between when the system is finished syncing and when >the power is turned off. This might be the best solution for FreeBSD, as >well, but it will irritate people. The Windows solution is, apparently, to disable and immediately re-enable the writeback-cache around a barrier. This will ensure the cache being written out to the platters, even if the drive ignores a flush command. Of course I don't know this for certain but have to rely on observations that others have made. See, for example: http://mail-index.netbsd.org/tech-kern/2002/12/09/0052.html The long delay at shutdown would simply be a final safeguard in case the drive also ignores disabling of the WC. mkb.