From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262271AbTEMXma (ORCPT ); Tue, 13 May 2003 19:42:30 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262318AbTEMXma (ORCPT ); Tue, 13 May 2003 19:42:30 -0400 Received: from pc2-cwma1-4-cust86.swan.cable.ntl.com ([213.105.254.86]:19615 "EHLO lxorguk.ukuu.org.uk") by vger.kernel.org with ESMTP id S262271AbTEMXm3 (ORCPT ); Tue, 13 May 2003 19:42:29 -0400 Subject: Re: 2.5.69, IDE TCQ can't be enabled From: Alan Cox To: Andre Hedrick Cc: Jens Axboe , Jeff Garzik , Dave Jones , "Mudama, Eric" , Oleg Drokin , Bartlomiej Zolnierkiewicz , Oliver Neukum , lkhelp@rekl.yi.org, Linux Kernel Mailing List In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1052866550.1205.13.camel@dhcp22.swansea.linux.org.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 13 May 2003 23:55:52 +0100 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Maw, 2003-05-13 at 21:03, Andre Hedrick wrote: > Not a single OS (linux included) can deal with a error in flush cache, > much less an error from a previous tagged request. To be reasonable its not clear what you can do when a flush cache fails. The only cases I can see you can handle anything intelligently are drive side but even those are not clear. If the drive flushes all the blocks it can get to disk its really the same as a fatal write error except we have less idea how to recover and have already lost the data. For the cases it matters you turn off write cache and we (maybe SATA time mostly) get tcq working properly. This is the same issue as with SCSI. SCSI has a whole rats nest of things that seem to exist solely to screw up error recovery 8)