From owner-freebsd-stable Thu Jun 20 15:11:38 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 1890A37B400 for ; Thu, 20 Jun 2002 15:11:29 -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 15:11:28 -0700 From: "Philip J. Koenig" Organization: The Electric Kahuna Organization To: Nick Sayer Date: Thu, 20 Jun 2002 15:11:27 -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: stable@FreeBSD.ORG, Matthias Andree In-reply-to: <3D124F7C.6090302@kfu.com> X-mailer: Pegasus Mail for Win32 (v3.12c) Message-ID: <20020620221128504.AAA673@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 On 20 Jun 2002, at 14:56, Nick Sayer boldly uttered: > Philip J. Koenig wrote: > > > > >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"? > > > > Because the OS is notified when the write is actually completed. That > makes it safe, because softupdates can insure that writes occur in a > particular order (that is, write #2 is not scheduled until it is known > that write #1 completes). This doesn't make sense to me, because I thought the whole point of on-disk write-caching is immediately notifying the OS that a write has completed - even though in fact it's only been written to cache, and not necessarily to disk yet. Are you saying that for some reason with ATA tagged command queuing, there are 2 notifications: one when the requested write is acknowledged (or written to on-board disk cache) and one when the write to the platters actually occurs? Otherwise if it's just the latter, I would think there would be no performance advantage over no write-cache, because the OS would still wait for acknowledgement of the actual disk write - just like it does with no write-caching at all. -- 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