Re: blacklist of hard drives that misreport serial numbers

[Ethan Baldridge <baldridge.ethan@gmail.com>]

On Thu, 2010-06-10 at 23:36 -0400, David Zeuthen wrote:
> Hi,
> 
> On Thu, Jun 10, 2010 at 10:58 PM, Ethan Baldridge
> <baldridge.ethan@gmail.com> wrote:
> > Does such a list exist?
> >
> > I've got a system that depends on the symlink in /dev/disk/by-id to
> > identify which of the external drives at our datacenter contains the
> > data that needs to be removed and shipped out after we export to the
> > drive.
> >
> > This worked fabulously during in-house testing, but now that the system
> > is in production we find that some Toshiba drives (at least) don't
> > report a serial number to the OS that looks anything like what is
> > printed on the outside of the drive itself. That complicates things.
> >
> > Is this dastardly behavior limited to Toshiba, or merely the specific
> > model in question, or is it a known widespread problem for drives from
> > any vendor (and is it at least guaranteed that certain models are safe)?
> 
> For SCSI disks (e.g. data obtained via scsi_id), ID_SERIAL isn't
> really the page 0x80 serial number that is typically printed on the
> label of the hard disk. This commit has some more information
> 
> http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;hN9fdfccbdd16f0cfdb5c8fa8484a8ba0f2e69d3
> 
> and exports the serial number and WWN in ID_WWN and ID_SCSI_SERIAL.
> 
> FWIW, I don't think we use ID_SCSI_SERIAL in any /dev/disk symlinks
> but we probably could. Any chance you could try seeing if
> ID_SCSI_SERIAL works for you? It's available since udev version 148 or
> later.
> 
> Also, we do use ID_WWN for /dev/disk/by-id/wwn-0x* symlinks (and this
> is set for both SCSI (including e.g. SAS) through scsi_id and ATA
> through ata_id) - maybe you can use the by-id/wwn-* symlinks instead?
> 
>     David

Thanks for the info, David, but unfortunately these are USB drives, and
scsi_id doesn't seem to return anything (although this is with udev
version 147, so I can try upgrading, but that patch only seems to affect
the scsi subsystem - has something similar been done to usb?)

$ /lib/udev/usb_id -x /block/sdg
ID_VENDOR=Toshiba
ID_VENDOR_ENC=Toshiba\x20
ID_VENDOR_ID\x0480
ID_MODEL=External_USB_HDD
ID_MODEL_ENC=External\x20USB\x20HDD
ID_MODEL_ID 03
ID_REVISION\x010f
ID_SERIAL=Toshiba_External_USB_HDD_2010040104E4-0:0
ID_SERIAL_SHORT 10040104E4
ID_TYPE=disk
ID_INSTANCE=0:0
ID_BUS=usb
ID_USB_INTERFACES=:080650:
ID_USB_INTERFACE_NUM\0
ID_USB_DRIVER=usb-storage

$ /lib/udev/scsi_id -x /block/sdg
$

Versus this result for a Seagate drive:
$ /lib/udev/usb_id -x /block/sdf
ID_VENDOR=Seagate
ID_VENDOR_ENC=Seagate\x20
ID_VENDOR_ID\vc2
ID_MODEL=FreeAgentDesktop
ID_MODEL_ENC=FreeAgentDesktop
ID_MODEL_ID000
ID_REVISION\x100F
ID_SERIAL=Seagate_FreeAgentDesktop_5QM0A7X7-0:0
ID_SERIAL_SHORT=5QM0A7X7
ID_TYPE=disk
ID_INSTANCE=0:0
ID_BUS=usb
ID_USB_INTERFACES=:080650:
ID_USB_INTERFACE_NUM\0
ID_USB_DRIVER=usb-storage

And this number actually does match what one would expect by looking at
the bottom of the drive enclosure.

The serial is used in the symlinks in by-id here:
lrwxrwxrwx 1 root root  9 2010-05-13 14:32
usb-Seagate_FreeAgentDesktop_5QM0A7X7-0:0 -> ../../sdf
lrwxrwxrwx 1 root root 10 2010-05-13 14:32
usb-Seagate_FreeAgentDesktop_5QM0A7X7-0:0-part1 -> ../../sdf1
lrwxrwxrwx 1 root root  9 2010-05-20 17:25
usb-Toshiba_External_USB_HDD_2010040104E4-0:0 -> ../../sdg
lrwxrwxrwx 1 root root 10 2010-05-20 17:25
usb-Toshiba_External_USB_HDD_2010040104E4-0:0-part1 -> ../../sdg1
lrwxrwxrwx 1 root root  9 2010-06-09 10:37
usb-Toshiba_External_USB_HDD_2010040105DD-0:0 -> ../../sde
lrwxrwxrwx 1 root root 10 2010-06-09 10:37
usb-Toshiba_External_USB_HDD_2010040105DD-0:0-part1 -> ../../sde1


Thanks,
Ethan