Custom Query (1559 matches)

Just noticed that these HPE Micron branded SSDs do not show all attributes and they aren't in the latest hard drive database.

I believe they are based on the Micron 5200 Eco MTFDDAK1T9TDC.

smartctl -P showall 'HP VK001920GWSXK' No presets are defined for this drive. Its identity strings: MODEL: HP VK001920GWSXK FIRMWARE: (any)

Hi,

I'm reporting an issue where smartd uses cached device information when a device path gets reassigned to a different physical drive, leading to incorrect device identification in alert emails.

I initially reported this to Proxmox VE (​https://bugzilla.proxmox.com/show_bug.cgi?id=6875) but they confirmed it's a smartmontools behavior that should be addressed upstream.

Here's what happened: My Proxmox host has a SATA controller with PCIe passthrough to a TrueNAS VM. During boot, smartd scans all devices including a 16TB Seagate ST16000NM000J on that controller. After boot, the controller is passed through to the VM. Later, I connected a 4.5TB USB drive with SMART errors that appeared as /dev/sda.

When smartd detected 2435 pending sectors on /dev/sda, the email alert showed the serial number, model, and capacity of the Seagate drive instead of the actual USB drive. The Seagate was never /dev/sda on Proxmox - smartd just cached its information during the initial scan and reused it when a different drive appeared at that path.

This is problematic because administrators might replace the wrong drive based on incorrect serial numbers, while the actually failing drive goes unnoticed. Device paths like /dev/sdX aren't stable identifiers, and smartd should either detect when a device has changed (via WWN/serial mismatch) or re-query the device before sending alerts.

As a workaround, I can configure smartd to explicitly exclude or include specific devices, but the default behavior of trusting cached information for reassigned device paths seems fundamentally unsafe for modern dynamic storage environments with hot-swappable bays, USB drives, or passthrough configurations. Is this the intended behavior, or could smartd be made to verify device identity before using cached information?

Thanks

smartctl -a gives here:

[...] ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE [...]

9 Power_On_Hours 0x0012 001 001 000 Old_age Always - 66120

[...] SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Short offline Completed without error 00% 572 - # 2 Short offline Completed without error 00% 548 - # 3 Short offline Completed without error 00% 524 - # 4 Short offline Completed without error 00% 500 - # 5 Short offline Completed without error 00% 476 - # 6 Short offline Completed without error 00% 452 - # 7 Short offline Completed without error 00% 428 - # 8 Short offline Completed without error 00% 404 - # 9 Short offline Completed without error 00% 380 - #10 Short offline Completed without error 00% 356 - #11 Short offline Completed without error 00% 332 - #12 Short offline Completed without error 00% 308 - #13 Short offline Completed without error 00% 284 - #14 Short offline Completed without error 00% 260 - #15 Short offline Completed without error 00% 236 - #16 Short offline Completed without error 00% 212 - #17 Short offline Completed without error 00% 188 - #18 Short offline Completed without error 00% 164 - #19 Short offline Completed without error 00% 140 - #20 Short offline Completed without error 00% 116 - #21 Short offline Completed without error 00% 92 -

As you can see, in the SMART attributes, the life time (Power_On_Hours) is OK: 66120. But in the log, it has wrapped at 65536.

Found in 5.38 and svn revision 2879 Original bug report: ​http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535298