From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ric Wheeler Subject: Re: USB storage & write barrier support? Date: Mon, 23 Nov 2009 15:57:48 -0500 Message-ID: <4B0AF74C.6070600@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org To: Alan Stern Return-path: Received: from mx1.redhat.com ([209.132.183.28]:31737 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755468AbZKWUwq (ORCPT ); Mon, 23 Nov 2009 15:52:46 -0500 In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 11/23/2009 03:49 PM, Alan Stern wrote: > On Mon, 23 Nov 2009, Ric Wheeler wrote: > >> What we need is to pass down cache flush commands (ATA_CACHE_FLUSH_EXT is what >> flushed the cache for ATA/S-ATA devices). Even with a command-queue length of 1, >> the write cache a USB connected s-ata drive would still loose data on power off >> without this kind of support. > > You can't send ATA commands directly over a USB connection without > using a passthru protocol of some sort. Some of the USB interfaces in > various drive enclosures support such a protocol but a lot of them > don't. > > Of course, you _can_ send SCSI's SYNCHRONIZE CACHE command. What > ATA/SATA command (if any) the drive's USB interface will translate it > into is known only to the interface's manufacturer. Nevertheless, > that's what we've been depending on because that's what the sd driver > uses. > > Alan > That makes sense - so the usb storage stack does the right thing, what happens is up to the SCSI -> ATA translation in the target device. If I still had occasional access to analyzers, we could always test & verify that some of the common enclosures work correctly but I have unfortunately lost my toys :-) Thanks! Ric