USB storage & write barrier support?

USB storage & write barrier support?

[Ric Wheeler]

Hi Alan,

One quick question - how robust is our support for write barriers over USB?

Specifically, I am looking to get together some testing with both 
external USB and e-sata enclosure for various file systems and would be 
very interested in helping make sure that this is well handled...

Best regards,

Ric

Re: USB storage & write barrier support?

[Alan Stern]

On Mon, 23 Nov 2009, Ric Wheeler wrote:

> Hi Alan,
> 
> One quick question - how robust is our support for write barriers over USB?
> 
> Specifically, I am looking to get together some testing with both 
> external USB and e-sata enclosure for various file systems and would be 
> very interested in helping make sure that this is well handled...

It's extremely robust -- the USB mass-storage driver has a maximum 
command-queue length of 1!

With the coming of USB 3.0 and the UASP (USB-Attached SCSI Protocol)
specification this will change.  I presume barriers will then be
implemented as the need arises.

Alan

Re: USB storage & write barrier support?

[Ric Wheeler]

On 11/23/2009 03:37 PM, Alan Stern wrote:
> On Mon, 23 Nov 2009, Ric Wheeler wrote:
>
>> Hi Alan,
>>
>> One quick question - how robust is our support for write barriers over USB?
>>
>> Specifically, I am looking to get together some testing with both
>> external USB and e-sata enclosure for various file systems and would be
>> very interested in helping make sure that this is well handled...
>
> It's extremely robust -- the USB mass-storage driver has a maximum
> command-queue length of 1!
>
> With the coming of USB 3.0 and the UASP (USB-Attached SCSI Protocol)
> specification this will change.  I presume barriers will then be
> implemented as the need arises.
>
> Alan
>

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.

Ric

Re: USB storage & write barrier support?

[Alan Stern]

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

Re: USB storage & write barrier support?

[Ric Wheeler]

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