public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: "Jan-Jonas Sämann" <sprinterfreak@binary-kitchen.de>
To: pve-devel@lists.proxmox.com
Subject: [pve-devel] New routine get_wear_leveling_info()
Date: Sat, 24 Oct 2020 21:27:08 +0200	[thread overview]
Message-ID: <20201024192709.27324-1-sprinterfreak@binary-kitchen.de> (raw)
In-Reply-To: <4e2bd780-260b-d757-e108-8ea8bb57c0df@proxmox.com>

Hi,

upon closer inspection and more testing on different systems, I also
discovered more issues with the current implementation itself. Hence
registers can vary on model bases for some vendors, it is clearly not
the correct way to map registers. The current implementation
even interprets entirely unrelated registers on some drives.
For instance on a Corsair SSD of mine Register 233 (default) is used,
wich according to smartctl is labeled as "Sandforce_Internal"

I am currently working on a different approach wich uses attribute names
from smartmontools drivedb.h to search for the correct register. This
way we can build up on existing knowledge. In theory and after more
testing, the new method could entirely replace the current lookup
procedure.  Sadly even smartmontools does not provide a generic label
for the closest possible wearout predicting value. So we still need to
look up the next best label and let smartctl translate down to the
register address.

It doesn't make sense to me anymore to maintain the kind of qnd
vendormap like Dominik allready said.

kind regards
Jan





  reply	other threads:[~2020-10-24 19:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-19 22:53 [pve-devel] [PATCH] disk management: Add support for additional Crucial SSDs Jan-Jonas Sämann
2020-10-22 13:30 ` Dominik Csapak
2020-10-24 19:27   ` Jan-Jonas Sämann [this message]
2020-10-24 19:27     ` [pve-devel] [PATCH v2 storage] Diskmanage: Use S.M.A.R.T. attributes for SSDs wearout lookup Jan-Jonas Sämann
2020-10-27  8:08       ` Thomas Lamprecht
2020-10-27 19:06         ` Jan-Jonas Sämann
2020-10-29 18:21       ` Thomas Lamprecht
2020-10-30  3:31         ` [pve-devel] Updated patch and test data Jan-Jonas Sämann
2020-10-30  3:31           ` [pve-devel] [PATCH storage v3 1/2] Update disk_tests/ssd_smart/sde data Jan-Jonas Sämann
2020-10-30  3:57             ` [pve-devel] Commit fixup Jan-Jonas Sämann
2020-10-30  3:57               ` [pve-devel] [PATCH storage v4 1/2] Update disk_tests/ssd_smart/sde data Jan-Jonas Sämann
2020-10-30 14:32                 ` [pve-devel] applied: " Thomas Lamprecht
2020-10-30  3:57               ` [pve-devel] [PATCH storage v4 2/2] Diskmanage: Use S.M.A.R.T. attributes for SSDs wearout lookup Jan-Jonas Sämann
2020-10-30 14:32                 ` [pve-devel] applied: " Thomas Lamprecht
2020-10-30  3:31           ` [pve-devel] [PATCH storage v3 " Jan-Jonas Sämann

Reply instructions:

You may reply publicly 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=20201024192709.27324-1-sprinterfreak@binary-kitchen.de \
    --to=sprinterfreak@binary-kitchen.de \
    --cc=pve-devel@lists.proxmox.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal