On 08.06.2019 12:12, Konstantin Khlebnikov wrote:
On 07.06.2019 19:58, Martin K. Petersen wrote:
Konstantin,
+ if (dev->horkage & ATA_HORKAGE_NOTRIM)
+ trim_status = "backlisted";
blacklisted
Oops. My bad.
+ else
+ trim_status = "supported";
+
+ if (!ata_fpdma_dsm_supported(dev))
+ trim_queued = "no";
+ else if (dev->horkage & ATA_HORKAGE_NO_NCQ_TRIM)
+ trim_queued = "backlisted";
ditto
+ else
+ trim_queued = "yes";
Why is trim_status "supported" and trim_queued/trim_zero "yes"?
Hmm. This seems properties of trim, not independent features.
+
+ if (!ata_id_has_zero_after_trim(id))
+ trim_zero = "no";
+ else if (dev->horkage & ATA_HORKAGE_ZERO_AFTER_TRIM)
+ trim_zero = "yes";
+ else
+ trim_zero = "maybe";
+
+ ata_dev_info(dev, "trim: %s, queued: %s, zero_after_trim: %s\n",
+ trim_status, trim_queued, trim_zero);
+ }
+
Otherwise no particular objections. We were trying to limit noise during
boot which is why this information originally went to sysfs instead of
being printed during probe.
On 08.06.2019 11:25, Christoph Hellwig wrote:> On Fri, Jun 07, 2019 at 10:34:39AM +0300, Konstantin Khlebnikov wrote:
>
> Do we really need to spam dmesg with even more ATA crap? What about
> a sysfs file that can be read on demand instead?
>
Makes sense.
Trim state is exposed for ata_device: /sys/class/ata_device/devX.Y/trim
but there is no link from scsi device to ata device so they hard to match.
I'll think about it.
Nope. There is no obvious way to link scsi device with ata_device.
ata_device is built on top of "transport_class" and "attribute_container".
This some extremely over engineered sysfs framework used only in ata/scsi.
I don't want to touch this.
