Re: "SilverStone TS16" external SSD enclosing needs an UAS quirk

[Bruno Haible <bruno@clisp.org>]

Alan Stern wrote:
> > > Slowing down all RTL9120 already in the market with this quirk is in my 
> > > humble opinion not a realistic solutio.
> > 
> > What else do you propose, for those of us who buy this hardware (€ 50,
> > it wasn't a cheap one), connect it directly to a computer (through the
> > vendor-provided cable, to an USB-C 3.2 Gen.2 connector, as in my case),
> > and then experience 1-2 crashes per day under Linux?
> 
> The proposal is that you keep on doing what you've been doing: Set the 
> UAS quirk.  Then your system will work, and others who don't have the 
> same problem will get to keep the advantage of quicker transfers with 
> the uas driver.

There's obviously a speed vs. reliability tradeoff here.

On the speed side: Do you know the speed difference between an external
SSD with uas driver vs. an external SSD with usb-storage driver?

On the reliability side: It makes the difference between a usable and
an unusable computer. I don't understand why you seem to prefer that
I have, by default, a fast but unusable computer rather than a reliable,
even if speed-limited, computer. Isn't it the opposite throughout the
industry? (For example, the CPU clock is not overclocked _by_default_.
An admin can overclock it, but the default is to be reliable.)

You say "Set the UAS quirk", as if it was something completely immediate
to do.

  - As a tech-savvy person (and former Linux kernel developer), it took
    me 3 days of investigations, web searches, and reading of kernel
    command-line documentation, in order to get at the solution.

  - For a non-tech-savvy person, it's basically impossible to arrive
    at the solution you propose. They would have summarized their experience
    as "Linux is not made for the desktop, let me choose another OS".

Isn't there a more intelligent solution to this problem? For example, the
uas_eh_abort_handler could, instead of just logging the problem, tell a
system daemon that the configuration of the particular device is problematic,
and that system daemon would change the grub.cfg (or some other file that
stores kernel command-line parameters), so that the quirk gets activated
automatically at the next reboot.

Bruno