Custom Query (1557 matches)

Dear Smartmontools-Team,

I propose an update to the drivedb.h file in order to correctly support the Toshiba MG-Series harddrives. The current Regexes do not cover all drive models (especially the SAS-Models are not covered). The proposed changes can be found in the attached diff file.

Information on the MG-Series drives are sourced from this Toshiba datasheet: ​https://www.toshiba-storage.com/wp-content/uploads/2018/04

Toshiba Model numbers have the following meaning:

1-4   Series Number
       MGnn: with nn in 04,05,05,06,07,08,09,10
5     Interface
       A: SATA
       S: SAS
6     RPM
       C: 7,200 rpm
7     Height
       A: 26.1 mm
       F: unknown
8-10  Formatted Capacity
       400: 4 TByte
       600: 6 TByte
       800: 8 TByte
       10T: 10 TByte
       12T: 12 TByte
       14T: 14 TByte
       16T: 16 TByte
       20T: 20 TByte
       22T: 22 TByte
11-12 Options
       A: 4K Native (4Kn) AF
       E: 512 B Emulation (512e) AF
       N: 512 B Native (512n) Format
       AY: 4K Native (4Kn) AF and SIE ( Sanitize Instant Erase )
       EY: 512 B Emulation (512e) AF and SIE ( Sanitize Instant Erase )
       NY: 512 B Native (512n) Format and SIE ( Sanitize Instant Erase )

See also: ​https://toshiba.semicon-storage.com/ap-en/storage/support/storage-products-hdd.html

However, I belive this support page describing the model numbers is not 100% correct!

I hope that helps improving smartmontools.

Best regards Sascha

Dear Smartmontools-Team,

I propose an update to the drivedb.h file in order to correctly support the latest Seagate IronWolf Pro harddrives.

OLD REGEX: ST8000NE0004-1ZF11G/EN01, ST8000NE0021-2EN112/EN02, ST16000NE000-2RW103/EN02 "ST([24]000NE0025|4000NE001|6000NE0023|8000NE00(04|08|21)|(10|12|14)000NE000[478]|16000NE000)-.*",

NEW REGEX: ST8000NE0004-1ZF11G/EN01, ST8000NE0021-2EN112/EN02, ST16000NE000-2RW103/EN02, ST8000NE001-2M7101/EN01 "ST(22|20|18|16|14|12|10|8|6|4|2)000N[ET]0?0(00|01|04|07|08|21|25)-.*",

The proposed regex was derived from the drives mentioned in the current drivedb.h and the official Seagate IronWolf Pro datasheet.

​https://www.seagate.com/content/dam/seagate/de_de/content-fragments/products/datasheets/ironwolf-pro-12tb/ironwolf-pro-20tb-DS2129-3-2306US-de_DE.pdf

Information on Seagate model numbering can be found here: ​https://www.seagate.com/files/staticfiles/docs/pdf/marketing/st-model-number-cheat-sheet-sc504-1-1102us.pdf

Regex was tested with: smartctl -P showall <MODEL NUMBER>-2M7101 Were <MODEL NUMBER> was replaced by all model numbers in the current drivedb.h and the datasheet.

Further tested by smartctl -a /dev/ada1 with an ST8000NE001-2M7101 drive.

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