linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris Paulson-Ellis <chris@edesix.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: /dev/disk/by-id incomplete and unhelpful for SATA drives
Date: Thu, 22 Dec 2005 11:24:59 +0000	[thread overview]
Message-ID: <43AA8D0B.10504@edesix.com> (raw)
In-Reply-To: <doc5jl$acv$1@sea.gmane.org>

Kay Sievers wrote:
> On Wed, Dec 21, 2005 at 09:57:52PM +0000, Chris Paulson-Ellis wrote:
>>Kay Sievers wrote:
>>>On Wed, Dec 21, 2005 at 06:05:17PM +0000, Chris Paulson-Ellis wrote:
>>>>[snip]
>>>>http://bugs.gentoo.org/show_bug.cgi?id\x109582
>>>>[snip]
> 
> Sure, both disks have the same "serial number", which will create the
> same links, so the last one wins and replaces the links of the other
> disk.

Of course. I could have worked that out by myself if I'd thought about 
it for more than 2 minutes!

>>> [snip]
>>>What does:
>>> scsi_id -g -p0x80 -x -s /block/sda
>>> scsi_id -g -p0x83 -x -s /block/sda
>>>print?
>>
>>[snip]
> 
> These are the pages requested from the disk which contain all the
> product information. It's defined by the SCSI standard.
> 
>># scsi_id -g -p0x80 -x -s /block/sda
>>ID_VENDOR=ATA
>>ID_MODEL=Maxtor_6Y160M0
>>ID_REVISION=YAR5
>>ID_SERIAL=SATA_Maxtor_6Y160M0_Y4DCTR3E
>>ID_TYPE=disk
>>ID_BUS=scsi
>># scsi_id -g -p0x83 -x -s /block/sda
>>ID_VENDOR=ATA
>>ID_MODEL=Maxtor_6Y160M0
>>ID_REVISION=YAR5
>>ID_SERIAL
TA_Maxtor_6Y160M0_Linux_ATA-SCSI_simulator
>>ID_TYPE=disk
>>ID_BUS=scsi
>>
>>>[snip]
> 
> Try if putting:
>   vendor="ATA",options=-p 0x80
> in:
>   /etc/scsi_id.config
> helps.

Bingo. I added the following to /etc/scsi_id.config...

# Make SATA drives report sensible serial numbers
# instead of "Linux_ATA-SCSI_simulator"
vendor="ATA", options="-p 0x80"

...and now it works:

# tree /dev/disk
/dev/disk
|-- by-id
|   |-- scsi-SATA_Maxtor_6Y160M0_Y4DCTR3E -> ../../sda
|   |-- scsi-SATA_Maxtor_6Y160M0_Y4DCTR3E-part1 -> ../../sda1
|   |-- scsi-SATA_Maxtor_6Y160M0_Y4DCTR3E-part2 -> ../../sda2
|   |-- scsi-SATA_Maxtor_6Y160M0_Y4DCTR3E-part3 -> ../../sda3
|   |-- scsi-SATA_Maxtor_6Y160M0_Y4DCTVFE -> ../../sdb
|   |-- scsi-SATA_Maxtor_6Y160M0_Y4DCTVFE-part1 -> ../../sdb1
|   |-- scsi-SATA_Maxtor_6Y160M0_Y4DCTVFE-part2 -> ../../sdb2
|   |-- scsi-SATA_Maxtor_6Y160M0_Y4DCTVFE-part3 -> ../../sdb3
|   |-- usb-Maxtor_OneTouch_Y3LYJVEE -> ../../sdc
|   `-- usb-Maxtor_OneTouch_Y3LYJVEE-part1 -> ../../sdc1
|-- by-path
|   |-- pci-0000:00:1f.2-scsi-0:0:0:0 -> ../../sda
|   |-- pci-0000:00:1f.2-scsi-0:0:0:0-part1 -> ../../sda1
|   |-- pci-0000:00:1f.2-scsi-0:0:0:0-part2 -> ../../sda2
|   |-- pci-0000:00:1f.2-scsi-0:0:0:0-part3 -> ../../sda3
|   |-- pci-0000:00:1f.2-scsi-1:0:0:0 -> ../../sdb
|   |-- pci-0000:00:1f.2-scsi-1:0:0:0-part1 -> ../../sdb1
|   |-- pci-0000:00:1f.2-scsi-1:0:0:0-part2 -> ../../sdb2
|   |-- pci-0000:00:1f.2-scsi-1:0:0:0-part3 -> ../../sdb3
|   |-- usb-Y3LYJVEE:0:0:0 -> ../../sdc
|   `-- usb-Y3LYJVEE:0:0:0-part1 -> ../../sdc1
`-- by-uuid
     |-- 2b9ac501-a3c8-4860-a251-d639c78335fc -> ../../md/2
     |-- 5a4f4464-0b58-1068-a788-5c5b3e1f109d -> ../../sda1
     |-- 7293013d-38d3-5da5-73a1-1aa2d8ed4f07 -> ../../sda2
     |-- a5c7e1a4-0c32-4a43-8adb-e3d57ca82984 -> ../../md/0
     |-- c05c061d-124c-4011-9ec5-bfb794a31de2 -> ../../sdc1
     `-- cf90252c-3fef-9382-56cc-56dc7ce36f8e -> ../../sda3

I was also able to fix the problem by adding a udev rule to recognise 
the broken serial number and switch to using scsi_id with page 0x80, 
just after the first call to scsi_id in the by-id section:

KERNEL="sd*[!0-9]", ENV{ID_SERIAL}="*_Linux_ATA-SCSI_simulator", 
IMPORT="/sbin/scsi_id -g -x -s %p -d %N -p 0x80"

I'm not sure which fix is better. Perhaps the scsi_id.config fix, as the 
udev rule could contradict an entry in scsi_id.config, confusing the 
user. Then again, the rule is only run if neccessary and I prefer to 
have only one place to look (the udev rules) to see what is happening.

Either fix would be a useful addition to the default scsi_id.config or 
udev rules, unless the libata driver is changed to report different 
results from page 0x83 (but perhaps it is doing the right thing!).

Or perhaps scsi_id should use page 0x80 rather than 0x83 by default...

I was curious as to why my USB mass storage device, which is also 
presented as a SCSI device by the kernel doesn't have the same problem. 
Looking at the udev rules, it seems that "usb_id -x" is run first, then 
scsi_id is run only if the serial number is still unknown. usb_id works 
and it appears that scsi_id would work for the USB drive too, but again 
only if page 0x80 is used:

# usb_id -x /sys/block/sdc
ID_VENDOR=Maxtor
ID_MODEL=OneTouch
ID_REVISION\x0200
ID_SERIAL=Maxtor_OneTouch_Y3LYJVEE
ID_TYPE=disk
ID_BUS=usb
# scsi_id -g -p 0x80 -x -s /block/sdc
ID_VENDOR=Maxtor
ID_MODEL=OneTouch
ID_REVISION\x0200
ID_SERIAL=SMaxtor_OneTouch_Y3LYJVEE
ID_TYPE=disk
ID_BUS=scsi
# scsi_id -g -p 0x83 -x -s /block/sdc
2:0:0:0: Invalid page 0x83

Thanks for your help,
Chris.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

  parent reply	other threads:[~2005-12-22 11:24 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-21 18:05 /dev/disk/by-id incomplete and unhelpful for SATA drives Chris Paulson-Ellis
2005-12-21 18:55 ` Kay Sievers
2005-12-21 21:57 ` Chris Paulson-Ellis
2005-12-22  4:35 ` Kay Sievers
2005-12-22 11:24 ` Chris Paulson-Ellis [this message]
2005-12-22 18:35 ` Bill Nottingham
2005-12-22 21:08 ` David Liontooth
2005-12-22 22:48 ` Chris Paulson-Ellis
2005-12-23  0:12 ` Chris Paulson-Ellis
2006-01-06  1:36   ` patman
2006-01-06  2:57     ` Douglas Gilbert
2006-01-06 12:39       ` [PATCH] " Douglas Gilbert
2006-01-06 13:34         ` Chris Paulson-Ellis
2006-01-06 18:58           ` Patrick Mansfield
2006-01-06 19:46         ` Patrick Mansfield
2006-01-06 23:44           ` Douglas Gilbert
2006-03-06 20:08         ` Jeff Garzik
2006-03-07 17:05           ` Douglas Gilbert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43AA8D0B.10504@edesix.com \
    --to=chris@edesix.com \
    --cc=linux-hotplug@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).