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

[Hans de Goede]

Hi all,

ping? I would appreciate a reply here, esp. on the part
about exporting the US_FL_NO_ATA_1X flag being set to
userspace. I also have a request from the gnome-disks
people:

https://gitlab.gnome.org/GNOME/gnome-disk-utility/-/issues/205

To export some more info about UAS flags to userspace
and I would like any new userspace API for this to
cover as much userspace consumers as possible.

Regards,

Hans



On 4/26/21 10:47 AM, Hans de Goede wrote:
> Hi all,
> 
> Short self-intro: I was the maintainer of the kernel's UAS driver for a
> long time and I'm still somewhat involved in its development.
> 
> Recently an email was submitted to drop the code from the kernel which
> automatically disables UAS ATA passthrough for all Seagate devices:
> https://lore.kernel.org/linux-usb/02f8f171-635a-4ad7-f937-78f935568de2@redhat.com/T/#t
> 
> In this thread I got pointed to your wiki page about this:
> https://www.smartmontools.org/wiki/SAT-with-UAS-Linux
> so I thought it would be good to reach out to you to discuss this.
> 
> I am (and the other kernel devs involved are) not in favor of the suggested
> change, this behavior was added to the kernel because many Seagate
> enclosures completely hang upon receiving an ATA_12 or ATA_16 command, see e.g.:
> https://bugzilla.kernel.org/show_bug.cgi?id=79511
> https://bbs.archlinux.org/viewtopic.php?id=183190
> 
> 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.
> 
> 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
> the kernel mailinglist thread + the 4 devices marked as known to work from:
> https://www.smartmontools.org/wiki/Supported_USB-Devices
> 
> I also noticed on the SAT-with-UAS-Linux wikipage that not being able to
> detect if the US_FL_NO_ATA_1X flag is set for a drive using UAS is
> problematic for smartmontools. If this would be useful for you I can write
> a kernel patch to expose this info somewhere in sysfs under one of the
> parent devices of the drive (either the host or the USB-interface or
> USB-device, I need to check where I can cleanly add this).
> 
> I can either add a dedicated sysfs file for this, or (maybe better)
> report all the flags which can be set with the quirks parameter using the
> same flag characters as the on the commandline / module-parameter.
> 
> Please let me know if this would be useful for you and if you have any
> preferences as to what form the userspace API for this should have.
> 
> Regards,
> 
> Hans
> 
> p.s.
> 
> I know that kernel-devs have a reputation as being hard to communicate with
> and I guess that for some parts of the kernel-community that is somewhat
> deserved but in general we don't bite. I'm somewhat surprised that there is
> a whole wikipage about this but no one ever reached out to me to discuss
> this (or maybe my memory is failing me?).
> 
> 
> 1) This will only be available inside the kernel, since a
> usb_storage.quirks= setting on the kernel commandline without the
> t flag already allows overriding the US_FL_NO_ATA_1X flag
>