From owner-freebsd-current@FreeBSD.ORG Mon Jul 26 21:59:53 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E47D816A4CE; Mon, 26 Jul 2004 21:59:53 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C34A43D2F; Mon, 26 Jul 2004 21:59:53 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from pooker.samsco.org (scottl@localhost [127.0.0.1]) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i6QM6XCE084278; Mon, 26 Jul 2004 16:06:33 -0600 (MDT) (envelope-from scottl@freebsd.org) Received: from localhost (scottl@localhost)i6QM6X6L084275; Mon, 26 Jul 2004 16:06:33 -0600 (MDT) (envelope-from scottl@freebsd.org) X-Authentication-Warning: pooker.samsco.org: scottl owned process doing -bs Date: Mon, 26 Jul 2004 16:06:33 -0600 (MDT) From: Scott Long Sender: scottl@pooker.samsco.org To: Matthias Andree In-Reply-To: Message-ID: <20040726155712.R32601@pooker.samsco.org> References: <1090718450.2020.4.camel@illusion.com> <200407251112.46183.doconnor@gsoft.com.au> <20040726175219.GA96815@green.homeunix.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: current@freebsd.org cc: bugghy Subject: Re: magic sysrq keys functionality X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2004 21:59:54 -0000 On Mon, 26 Jul 2004, Matthias Andree wrote: > Scott Long writes: > > > GAH! No, please don't start this war again! The last time that we tried > > turning this off in a release (4.1 IIRC), were were plagqued by months of > > earthquakes, plagues, and deaths of first-born youngsters. I 100% agree > > that write caching in ATA is not compatible with data integrety, but the > > ATA marketting machine has convinced us that cached+untagged speed is > > better than uncached+tagged safety. C'est la vie, or so they say here. > > Looking out of the cosy FreeBSD hut, for the Linux kernel, write barrier > support (i. e. using the ATA cache flush facility on those drives that > support it, and logging a warning if a drive doesn't) to enforce proper > write order and synchronization is underway, with some distros already > using it, for instance SuSE. It's not yet in the baseline code AFAIK. > > BTW, is proper write order guaranteed on SCSI drives through ordered > tags? softdep doesn't really like blocks being written in different > order than scheduled. > I don't believe that any order is guaranteed. FreeBSD used to have the concept of a B_ORDERED bio flag that would help order the bioq, but it was removed early in the 5-current cycle due to apparent non-use. It's tough to rely on ATA Flush Cache since many devices exist that advertise it but don't actually support it (i.e. they lock up if you try it). SCSI certainly supports it, but again it was information that was never getting to the device. Some SCSI drivers compensate by sending periodic ordered tags to help decrease the chances for an out-of-order commit, but it's still a small gamble. This works right now because we assume that disks will commit blocks in order, and that assumption generally hasn't been broken. If legacy ATA were to drop off the face of the earth and drive makers were to commit to producing honest and non-buggy firmware, I'd love to bring back B_ORDERED and make it actually work. Scott