From owner-freebsd-stable Thu Jun 20 14:11:29 2002 Delivered-To: freebsd-stable@freebsd.org Received: from empty1.ekahuna.com (empty1.ekahuna.com [198.144.200.196]) by hub.freebsd.org (Postfix) with ESMTP id F1CA237B416 for ; Thu, 20 Jun 2002 14:11:20 -0700 (PDT) Received: from pc-02 (pc02.ekahuna.com [198.144.200.197]) by empty1.ekahuna.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Thu, 20 Jun 2002 14:11:21 -0700 From: "Philip J. Koenig" Organization: The Electric Kahuna Organization To: stable@FreeBSD.ORG Date: Thu, 20 Jun 2002 14:11:19 -0700 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: ATA Atapi 4.6 Release Reply-To: pjklist@ekahuna.com Cc: Matthias Andree In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.12c) Message-ID: <20020620211121029.AAA600@empty1.ekahuna.com@pc02.ekahuna.com> Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Date: Tue, 18 Jun 2002 17:25:52 +0200 > From: Matthias Andree > > Before telling others to be quiet: write cache without tagged queueing > is *unsafe* and may corrupt your data, softupdates forth or back. This > is not about speed alone, but about maintaining safety while going fast. > > There are exactly two safe bets: 1. write cache switched off or > 2. tagged queueing (which implies cache on). With FreeBSD 4.5, this is: > slow or fast. With FreeBSD 4.6, this is: slow or dead slow (because TQ > falls back to PIO after some timeouts). Excuse my ignorance but I was under the impression that (at least for SCSI) the sole function of tagged command queuing was to re-order a string of drive commands in order to perform them more efficiently - ie take into account sector position and latency to re-order things like seeks. (ie "elevator sorting" or "elevator seeking") Why does this magically make write-back drive-caching "safe"? Seems to me that if the power fails, there is still some unknown time "X" between the point at which the OS is told the write completed, and when the actual flushing of the drive cache to disk occurs, where data will become corrupted if that cache flush is still outstanding. -- Philip J. Koenig pjklist@ekahuna.com Electric Kahuna Systems -- Computers & Communications for the New Millenium To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message