From owner-cvs-all Mon Dec 6 22:15:14 1999 Delivered-To: cvs-all@freebsd.org Received: from mass.cdrom.com (castles552.castles.com [208.214.165.116]) by hub.freebsd.org (Postfix) with ESMTP id 5444F14D7D; Mon, 6 Dec 1999 22:15:06 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id WAA00550; Mon, 6 Dec 1999 22:17:09 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <199912070617.WAA00550@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Julian Elischer Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_shutdown.c In-reply-to: Your message of "Mon, 06 Dec 1999 22:04:04 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 06 Dec 1999 22:17:09 -0800 From: Mike Smith Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk >>>> Change the default poweroff delay from 0 to 5 seconds. This seems to be >>>> adequate for the IDE disks that I have available for testing. Most seem >>>> to wait between 1 and 3 seconds before flushing their caches. >>>> >>> We (whistle) added explicit commands to tell IDE drives to not cache >>> writes.. >>> I am not sure how generic they are.... >> >> Or whether they are at all desirable in the general case. >> >> A "better" fix would be to have the atadisk driver explicitly flush the >> cache on each drive while it's shutting down. This is just an expedient >> stopgap to save us in the meantime. > > Softupdates is pointless without this because Soft Updates cannot > guarantee the state of the filesystem to be sane unless the disk does not > lie about whether it has written to the disk. This is kinda immaterial except at completion boundaries. Whether you wait for the disk to flush its cache, or mandate that it flushes immediately after each transaction, the net result is the same. > Soft updates also makes all > the writes async, so who cares.. :-) Anyone who cares about the drive's ability to sort outstanding cache line writes for optimal throughput. > More precisely, the order of the writes must be absolutly maintained > and disks that buffer writes usually reserve the right to re-order > adjacent writes. This presumes that writes are entirely atomic, which I seem to recall you've previously stated (based on disk documentation) isn't guaranteed. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message