From: Douglas Gilbert <dougg@torque.net>
To: patman@aracnet.com
Cc: Chris Paulson-Ellis <chris@edesix.com>,
Bill Nottingham <notting@redhat.com>,
linux-hotplug-devel@lists.sourceforge.net,
linux-scsi@vger.kernel.org, linux-ide@vger.kernel.org
Subject: Re: /dev/disk/by-id incomplete and unhelpful for SATA drives
Date: Fri, 06 Jan 2006 02:57:50 +0000 [thread overview]
Message-ID: <43BDDCAE.7000506@torque.net> (raw)
In-Reply-To: <20060106013640.GA27841@aracnet.com>
patman@aracnet.com wrote:
> On Fri, Dec 23, 2005 at 12:12:18AM +0000, Chris Paulson-Ellis wrote:
>
>
>>>Why not just fix the kernel when it's filling in the page 83
>>>data to pull the serial from page 80 instead of putting *that* there?
>>>
>>>Bill
>>
>>Indeed. Here's the patch. Now I have 3 ways to fix this. Any more anyone?
>
>
> This is the best approach, I think you could even remove page 0x83 support
> and still be SCSI compliant.
Pat,
Not since 2000/2001 ... The VPD device identification page
(0x83) and the "Supported VPD pages" page (0x0) are
mandatory in SPC-2 (ANSI INCITS 351-2001), SPC-3 (soon
to be a standard) and SPC-4. Recent SCSI to ATA
Translation drafts (e.g. sat-r07a.pdf) define a mapping
for the naa-5 identifier defined in ATA/ATAPI-7 and
ATA/ATAPI-8 (IDENTIFY DEVICE response words 108 to 111)
to VPD page 0x83. There are also moves afoot to get a
similar wwn identifier into the IDENTIFY PACKET DEVICE
response.
SAT defines two device id descriptors for VPD page 0x83:
- based on WWN naa-5 (described above)
- based on model number and serial number (IDENTIFY
DEVICE response words 27-46 and 10-19)
So removing VPD page 0x83 would be a retrograde step
IMO. The libata implementation should be enhanced to
support one or both of the above descriptors as they
have a defined format (unlike serial number VPD page (0x80)).
libata's current approach to yield "Linux ATA-SCSI simulator"
for the loosely formatted ASCII identification descriptor
is just a place holder.
libata should do a lot more work in the VPD 0x83 page
area. For example when SATA disk is connected via SAS
(behind an expander rather that directly connected)
then a "device port" association descriptor should have
the SAS address (also naa-5) of the SATA bridge (in the
expander).
libata is not the only way that the SCSI subsystem
will be seeing SATA disks. There are FC exclosures
out there filled with SATA disks that have a SAT
layer in the enclosure.
Doug Gilbert
cc-ed to linux-ide
-------------------------------------------------------
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
next prev parent reply other threads:[~2006-01-06 2:57 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
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 [this message]
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=43BDDCAE.7000506@torque.net \
--to=dougg@torque.net \
--cc=chris@edesix.com \
--cc=linux-hotplug-devel@lists.sourceforge.net \
--cc=linux-ide@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=notting@redhat.com \
--cc=patman@aracnet.com \
/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).