support UAS (USB Attached SCSI)

[pulkomandy]

This was introduced with USB3 and is an alternative to the traditional and quirky USB Mass Storage. It allows better performance as SCSI commands can be queued and executed out of order by the device.

​http://en.wikipedia.org/wiki/USB_Attached_SCSI

Support is available in Windows 8, Mac OS X 10.8, and Linux (not sure which version). UAS can be implemented over USB 2.0 as well.

[waddlesplash]

Are you sure we don't support this already: ​http://xref.plausible.coop/source/xref/haiku/src/add-ons/kernel/busses/scsi/usb/ ?

[pulkomandy]

This is not for UAS, this is for traditional mass storage which also uses SCSI commands, but does not allow queuing and out of order execution.

[waddlesplash]

I don't think so? I think that the "traditional mass storage which also uses SCSI commands is what the usb_disk driver handles: ​http://xref.plausible.coop/source/xref/haiku/src/add-ons/kernel/drivers/disk/usb/usb_disk/usb_disk.cpp#578

So I'm not sure what scsi/usb even is then. It looks like it doesn't compile anymore.

[pulkomandy]

This code looks like it was originally developped for BeOS and is an alternate driver for USB mass storage. It was imported along with other drivers from Siarzhuk back in 2006 and wasn't much touched since:

​https://git.haiku-os.org/haiku/log/src/add-ons/kernel/busses/scsi/usb

I don't know what we should do with it. It may be cleaner than our current USB mass storage driver, and apparently can handle both bulk and cbi devices (so it should work also for USB floppy drives).

Maybe someone with more memory from these days can enlightnen us?

[waddlesplash]

On the contrary, it looks *far* messier than the current driver, and doesn't even build to boot.

We have USB floppy support from a different driver anyway (this should be folded back into the regular usb_disk driver, though.)

[pulkomandy]

Yes, usb_floppy should be merged with usb_disk *and* they should both be made to use the generic SCSI code instead of rolling their own thing with a subset of the commands. But, this may be a problem as using some SCSI commands will confuse some mass storage devices (eg. mobile phones, MP3 players) which implement exactly the subset of the spec used by windows mass storage drivers.

[korli]

Another reason is that the USB stack isn't ported to the new driver model.

[mmlr]

Well, maybe just look into the history:

Introduce a simple usb_disk driver that supports USB mass storage devices of
the bulk-only class using transparent SCSI commands (i.e. most of the current
external harddrives and flash media). It emulates the few SCSI commands needed
to get this sort of devices working and does not interface with the SCSI
subsystem. This makes it far easier to get working and also far better fits
how the USB stack works (as drivers can be dynamically rescanned when device
changes occur). This will allow for easy dynamic un- and replugging at runtime.

Note that this was way back in 2008. The situation then was that many USB mass storage devices were not actually implementing the SCSI layer. They just supported a tiny subset of fixed commands (probably hardcoded in firmware) and would just completely stall if you sent them anything outside of that subset. The usb_disk driver took the approach of using the most minimal subset of commands needed to make it more universally compatible (an approach which mostly worked out).

Drivers from other operating systems at that time sometimes took the same approach, some filtered the SCSI command set and others had large and growing lists of quirks to correct per device issues.

I do not know what the state of things is today. It may be worth a try to throw full SCSI at many devices and see how it goes. From past experience I'm not all that hopeful that devices have actually gotten better though, especially seeing the price range such products often fall into.

[pulkomandy]

Well, these old devices may still be around (one of my MP3 players is still problematic even with the current code in Haiku) so yes, maybe it's fine if it stays that way.

[cb88]

Replying to pulkomandy:

Well, these old devices may still be around (one of my MP3 players is still problematic even with the current code in Haiku) so yes, maybe it's fine if it stays that way.

That isn't the common case, wouldn't be be much better if a quirk could be added for your device? Then other devices wouldn't end up crippled on it's account etc...and your device would probably work. Every other major OS already does this so it isn't uncharted territory. There are some interesting links here ​https://github.com/ligurio/openbsd-tests/wiki/Device-drivers-testing

[waddlesplash]

It seems none of the BSDs support UAS even now. I am also seeing comments that there are still "UAS"-supporting drives which do not support the full SCSI command set, only just enough for them to work with Windows.

[pulkomandy]

It looks like this protocol wasn't very widely adopted by anyone. I don't remember why I created this ticket, I don't own any compatible hardware and I don't plan to. We can forget about this ticket until someone complains their hardware doesn't work, I guess.

[cb88]

I wouldn't say its not widely adopted, just not consistently... and its not easy to specifically search for UAS compliant devices to buy. Most likely newer controllers will continue to add support for it though. And it takes awhile for old stock of mass produced chips and things to sell off... and/or transition to newer chips. Even the cheapo sabrent enclosures support UAS these days though.

Case in point, identical case but the slightly newer one has a different chip ​https://www.jeffgeerling.com/blog/2020/uasp-makes-raspberry-pi-4-disk-io-50-faster

Even still its only around 50% more perf for hdparm and 8% power savings in that guys tests. And companies probably stopped advertising it because it got completely overshadowed by thunderbolt products. All in all probably doesn't acutally matter for Haiku but if someone wanted to implement it why not.