[smartmontools-support] Unbreaking Seagate UAS smart reporting at the kernel level

[Hans de Goede]

Hi,

On 5/4/21 1:53 PM, Nathan Stratton Treadway wrote:
> (Sorry, I missed the message when you first sent it.  I will try to
> write a longer response later, but here is a quick initial reply.)

No problem.

> [Note that I'm not part of the Smartmontools project, other than as a
> user -- and someone who was confused when my external Seagate drive
> inexplicably could not be accessed by hdparm/smartmontools on my newer
> computer but could just fine an older one... and ended up consolidating
> what I was able to track down in my research into that wiki page...]
> 
> 
> On Mon, Apr 26, 2021 at 10:47:45 +0200, Hans de Goede wrote:
>> My reasoning here is that having drives not hang (possibly while a
>> filesystem is mounted, causing fs damage) is more important then
>> having working SMART support. Note I'm not saying that SMART is not
>> important, I'm merly saying that having the basic storage functionality
>> of the drive working is even more important.
> 
> Fair enough. :) 
> 
>>
>> Still it would be good if we can both have our cake and eat it.
>>
>> So for now the plan is to add a new US_FL_ATA_1X_OK (1) flag to the set
>> of flags used by the usb_storage and uas drivers and set that for known
>> to work Seagate models. Which would product id 0xab03 from the starter of
> 
> In general it does sounds good to have the ability to better manage the
> whitelisting/blacklisting of specific drives (and especially for people
> who have one of the "it actually works" Seagates).
> 
> However, from the standpoint of the smartmontools/hdparm commands, what
> would be even nicer is some way to get SAT passthrough to work even when
> the drive is being used in UAS mode.  
> 
> The questions that came to my mind back when I was looking into this (but
> didn't find the answers at that time) were:
>   1) why does SAT pass-through work in usb-storage mode but not UAS?, and

Because Seagate (or a sub-contractor of seagate) messed up SAT support
in UAS mode and the controller/bridge chip which they use hangs when
you try to use it.

>   2) would there be a way for the UAS driver to somehow drop back to
>      some usb-storage-like USB communication in order to send the
>      SAT-pass through command to the drive?

Not really, for compatibility with OS-es which don't support UAS
the 2 are implement as 2 different USB configurations and we can only
switch USB configuration after detaching the UAS driver first
(after detaching all attached drivers), which is impossible when a
filesystem on the drive is mounted.

Theoretically we may be able to do something horrible to hack around this:

1. Pause all IO to the drive
2. finish all in flight IO.
3. Reset the device by issuing a low-level USB reset; and in the reset
callback in the UAS driver tell the USB midlayer that everything is cool
and that we can recover our state, so that it keeps the UAS driver bound to
the device.
4. Do the SAT and wait for it to complete in usb-storage bulk-transport mode
   (which would require duplicating a lot of the usb-storage code, since we
    cannot just use the usb-storage driver here)
5. Put the device back in UAS mode
6. resume IO

And then hope the SCSI layer does not time-out some of the paused commands
between 1. and 6. and also hope that 5 does not fail 5. failing would be
very bad.

But this would be a lot of work and very hacky and probably also a bit
fragile. SO IMHO this is just not worth the trouble.
If people want this fixef they should ask Seagate to provide firmware updates
for their enclosures to fix this on the end where the bug actually is.

Regards,

Hans