Linux-ide Archive on lore.kernel.org
 help / color / Atom feed
From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Stefan Tauner <tauner@technikum-wien.at>
Cc: linux-ide@vger.kernel.org
Subject: Re: Questions (and a possible bug) regarding the ata_device_blacklist and ATA_HORKAGE_ZERO_AFTER_TRIM
Date: Thu, 26 Sep 2019 18:01:03 -0400
Message-ID: <yq1pnjm1zvk.fsf@oracle.com> (raw)
In-Reply-To: <20190926150400.2524a63b@legacy>


Stefan,

> I don't know the technical details how this is communicated by the
> drive but I assume it's the same thing that smartctl and hdparm output
> as "Model Number" and "Device Model" respectively.

Yes.

> If this is correct (is it?) then there is a problem with the list
> AFAICT because the Crucial SSD I have reports this field simply as
> "CT500MX500SSD4" but the kernel expects "Crucial" at the beginning of
> almost all Crucial drives (line 4523+) including the vendor wildcard at
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/ata/libata-core.c#n4586
> Interestingly, in line 4520 there is an entry for the CT500BX100SSD1
> that does not start with "Crucial".

With a few exceptions, the entries in the libata white/blacklist were
submitted by Crucial/Micron themselves. But it's possible that they
changed their naming scheme.

> After looking into smartctl's drive database I guess the MX500 [2] (as
> well as BX100, BX200, BX300 and BX500 [1]) series stand out in this
> regard. This means that all of them do *not* get the
> ATA_HORKAGE_ZERO_AFTER_TRIM flag set because they are not matched by
> any of the model-specific entries nor the cumulative "Crucial*" vendor
> entry.

The newest drives I have are M550 models.

> I have not tested my drive to actually return zeros after trimming but
> from the kernel code I would assume that its intent is to match all
> Crucial SSDs and thus it is a bug mine is not matched. If someone
> tells me to the preferred method to test it I am happy to do this. If
> need be I can also submit a patch (just for MX500? all of the above?).

There's no way to exhaustively test. Many drives will return zeroes most
of the time but can have corner conditions that cause them to ignore
TRIM commands.

The ones we whitelisted were as a result of feedback from the vendors
themselves (thanks to an advertised qualification for use with hardware
RAID5 controllers). As you know, there is no way for a drive to express
this capability/guarantee in the ATA protocol.

> Is there any way to see which flags the kernel applies to a drive?

# grep . /sys/class/ata_device/*/trim
/sys/class/ata_device/dev1.0/trim:unqueued
/sys/class/ata_device/dev2.0/trim:queued

> Interestingly, "lsblk -D" does only show "0" for the Samsung device
> (although AFAICT it is matched by the white list AND reports
> "Deterministic read ZEROs after TRIM" according to hdparm. But I don't
> know what lsblk actually looks at...?

lsblk looks at /sys/block/*/queue/discard*

You get "0" for the discard granularity on the Samsung?

-- 
Martin K. Petersen	Oracle Linux Engineering

      reply index

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-26 13:04 Stefan Tauner
2019-09-26 22:01 ` Martin K. Petersen [this message]

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=yq1pnjm1zvk.fsf@oracle.com \
    --to=martin.petersen@oracle.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=tauner@technikum-wien.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-ide Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-ide/0 linux-ide/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-ide linux-ide/ https://lore.kernel.org/linux-ide \
		linux-ide@vger.kernel.org linux-ide@archiver.kernel.org
	public-inbox-index linux-ide

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-ide


AGPL code for this site: git clone https://public-inbox.org/ public-inbox