[RndTbl] Bug in smart reporting?

[Adam Thompson]

One scenario where you can see this is e.g. on the muug.ca server, where the drives are multipathed - i.e. two physical SAS channels reaching each drive.  Linux handles this by having two sdX nodes, then multipathd creates a single /dev/mapper/XXX device for you to use.

On a non-multipath box, this could happen if the drive went offline and then recovered.  I've seen it happen, but I don't know how to reproduce it.

My guess is it's the same drive, and the kernel decided it needed a new device name for some reason.  "dmesg|grep sd[gh]" might show you something useful?

-Adam

-----Original Message-----
From: Roundtable <roundtable-bounces at muug.ca> On Behalf Of Trevor Cordes
Sent: Monday, May 23, 2022 1:43 PM
To: MUUG RndTbl <roundtable at muug.ca>
Subject: [RndTbl] Bug in smart reporting?

Date: Mon, 23 May 2022 00:31:56 -0500
Device: /dev/sdg [SAT], 2 Currently unreadable (pending) sectors
Hitachi HDS723020BLA642, S/N:MN1220F317TJTD, WWN:5-000cca-369d1a23a,
FW:MN6OA580, 2.00 TB

Date: Mon, 23 May 2022 00:23:32 -0500
Device: /dev/sdh [SAT], 2 Currently unreadable (pending) sectors
Hitachi HDS723020BLA642, S/N:MN1220F317TJTD, WWN:5-000cca-369d1a23a,
FW:MN6OA580, 2.00 TB


No reboot in between... Note the SNs are identical.  That's impossible.
The drive models are probably truly the same, but the SNs certainly are
not.  I think I found a bug in smart, unless someone can think of a
reason why I'd be seeing this.

The problem is, I just relied on a smart email like this to decide
which drive to pull and replace.  Now I'm not so sure the smart
reporting is telling me anything correct.

This is on a fairly new Fedora and smartmontools-7.2-11

>From today forward I would recommend double-checking smart reports
before acting on them.  (smartctl -a, hdparm -i, etc)

_______________________________________________
Roundtable mailing list
Roundtable at muug.ca
https://muug.ca/mailman/listinfo/roundtable