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 _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
