From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 4254162368 for ; Sat, 24 Oct 2020 21:27:42 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 326112E397 for ; Sat, 24 Oct 2020 21:27:42 +0200 (CEST) Received: from lithium.binary-kitchen.net (lithium.binary-kitchen.net [IPv6:2a02:958:0:f6::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 1D8742E389 for ; Sat, 24 Oct 2020 21:27:41 +0200 (CEST) Received: from jayjay.reg.saenet.de (p5dc3c0b1.dip0.t-ipconnect.de [93.195.192.177]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by lithium.binary-kitchen.net (Postfix) with ESMTPSA id 931B24245F; Sat, 24 Oct 2020 21:27:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=binary-kitchen.de; s=mail-20190723; t=1603567655; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=AZXbxDyQeeCkrzQLCzQVrfdQtehp8dQtTZ13WRn3obA=; b=nI2j9VdNfGKuHsP9jIfV+suglWh02b3zgi1SEQHwgkJs5pEdckSGUpwu1yUFK7ypuTYym7 euRTQJ4tsTwBsodwai0YsjvqmAgdjyc6VhJHAtOdQpmO4XwSnHhDTceNWa6WMnaOSPJWNi 0ewGhRLwO4AJl4FZuvaIOY1MYRF+p+jQDkY1oK7qh1syzQOSMFmEDRMcUt4cp/KF758P2R /ZpGhIv3bih2xb/qU3/wQ8UEL8JUVjKyWo7bMSka562zr1ZOaqceqKz54rqwtdGn7cGNp3 LykqTTELjLdkslov9/qwwoxh2si6Y6LcyliiMe8A62ncjdr8BRsWv6szfgxc2xQUHOmoBi x8EILFSxZ/vN425LA1SqMxVvPd1YiJvtJVIMqzW6YKPlF0d0qFOboutoc/bWl2SlfJte+y rIwlMS09KVdhj59MPD4GgORGAqv6AyoT+qIKXV0MGeoOYE7mIz669lvFUnnSfEsMX+JBE0 toaaSOkCBJ6tkgwF/AuOdD1OGch4Gh+12lc00kVXiaRsqDf6rmzjJmzG9wU9b6FMrQsv9x 6tnbfOQSUCfue1KdyIYNmBSnRpHv4dtPPfhByu4TDMq81QsasRQE2c8wkK/hGCwa38XJIM XBYdMiZa17LoNrfXiQgtIWKisFeDwe75QhyXTiz4Dos93F2f69dXE= From: =?UTF-8?q?Jan-Jonas=20S=C3=A4mann?= To: pve-devel@lists.proxmox.com Date: Sat, 24 Oct 2020 21:27:08 +0200 Message-Id: <20201024192709.27324-1-sprinterfreak@binary-kitchen.de> X-Mailer: git-send-email 2.25.1 In-Reply-To: <4e2bd780-260b-d757-e108-8ea8bb57c0df@proxmox.com> References: <4e2bd780-260b-d757-e108-8ea8bb57c0df@proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Authentication-Results: ORIGINATING; auth=pass smtp.auth=sprinterfreak smtp.mailfrom=sprinterfreak@binary-kitchen.de X-SPAM-LEVEL: Spam detection results: 0 AWL -0.001 Adjusted score from AWL reputation of From: address DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [binary-kitchen.de] Subject: [pve-devel] New routine get_wear_leveling_info() X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2020 19:27:42 -0000 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