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

[Nathan Stratton Treadway]

(Answering some of your questions; more later...)

On Mon, Apr 26, 2021 at 10:47:45 +0200, Hans de Goede wrote:
> 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.
 
Yes, thanks for getting in touch!

I was curious if you've also tried to contact the hdparm developers or
community?  (I'm not involved in that project myself, but that program
relies on SAT pass-thru in the same way as smartmontools.)


> 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).
> 

Well, when I included that issue on the Wiki page, really it was in the
context of a user trying to figure out what is going on with their
device configuration:

   A) initially identifying why smartmontools isn't working with a
      particular USB enclosure, and

   B) checking whether a user's attempts at changing the quirks have had
      the desired effect (i.e. did the kernel actually see the
      configuration change and interpret it successfully?).

(Other people may well have different uses, and hopefully you will hear
from them, too...)

So from the standpoint of A), one quick suggestion would be to include a
kernel message in the Seagate-special-casing code, so that it's just as
obvious what's happening in that situation as it is when a
drive-specific flag is put into effect.

(Let me know if wordsmithing the exact message would be helpful....)


>From the standpoint of B), I think a quirks-report file for the UAS
driver would indeed be helpful.

My initial thought is that it would be easiest to document (e.g. on the
SAT-with-UAS-Linux page) if the file were actually parallel to the one
for usb-storage (/proc/scsi/uas/* ), and with a similar format.

But if /proc/scsi/ is deprecated now, a sysfs file would be fine.  (In
that case, would it be reasonable to have usb-storage also have a
matching file?   Personally I'd say a long-run trend to matching
reporting between the two drivers would be best, if possible.)


> 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.

Well, a dedicated file just for NO_ATA_1X would certainly be helpful for
the particular problems with smartmontools/hdparm, but (especially in
testing) I've used multple flags on one drive and I think it would be
confusing if the file only mentioned one of them.

(Or put another way, I have been glad that the /proc/scsi/usb-storage/*
files do show all the flags... :

# cat /proc/scsi/usb-storage/4 
   Host scsi4: usb-storage
       Vendor: Seagate
      Product: Backup+ RD
Serial Number: NA5CGDGD
     Protocol: Transparent SCSI
    Transport: Bulk
       Quirks: SANE_SENSE IGNORE_UAS NO_ATA_1X

)

							Nathan

----------------------------------------------------------------------------
Nathan Stratton Treadway  -  nathanst at ontko.com  -  Mid-Atlantic region
Ray Ontko & Co.  -  Software consulting services  -   http://www.ontko.com/
 GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239
 Key fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239