From: Caspar Smit <c.smit@truebit.nl>
To: "Desai, Kashyap" <Kashyap.Desai@lsi.com>
Cc: "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"Moore, Eric" <Eric.Moore@lsi.com>,
"Prakash, Sathya" <Sathya.Prakash@lsi.com>
Subject: Re: mpt2sas: bug in disk ordering?
Date: Fri, 13 May 2011 14:05:11 +0200 [thread overview]
Message-ID: <BANLkTinqCmZzc2E7G1-W0qB-p8domw4KYA@mail.gmail.com> (raw)
In-Reply-To: <B2FD678A64EAAD45B089B123FDFC3ED70157F7BB82@inbmail01.lsi.com>
Kashyap,
If the mpt2sas driver doesn't order the disks, how do you explain the
fact that the same HBA, with the same Firmware orders the disks
differently on two different driver versions? The firmware doens't
seem to have any effect on the drive ordering.
And how am i supposed to address and locate the disks in the chassis,
how can i be absolutely sure i'm changing the right (failed) disk when
something goes wrong in a linux raid set?
Why was the /dev/disk/by-path removed?
I am used to the fact that all disks in a chassis are ordered in linux
according to the slot numbers on the chassis, this is to ensure a
reliable RAID setup so that /dev/sdb for instance is always in a
certain slot in the chassis. So far I only used lsi 3081e-r
controllers and these always gave me solid and reliable disk
numbering. If this goes random, how am i supposed to keep track which
disk is where in the chassis?
Kind regards,
Caspar Smit
2011/5/13 Desai, Kashyap <Kashyap.Desai@lsi.com>:
> Smit,
>
> Disk ordering is not done by mpt2sas driver.
> Ordering is purely depend upon How FW discovers drivers and repots it to Driver.
>
> e.a if you have slow spinning driver at slot-0, it can be reported by FW at the end, though it is attached to slot-0.
>
> In summary, Disk ordering is not guaranteed.
>
> ~ Kashyap
>
>> -----Original Message-----
>> From: linux-scsi-owner@vger.kernel.org [mailto:linux-scsi-
>> owner@vger.kernel.org] On Behalf Of Caspar Smit
>> Sent: Friday, May 13, 2011 4:04 PM
>> To: linux-scsi@vger.kernel.org
>> Subject: Re: mpt2sas: bug in disk ordering?
>>
>> Hello again,
>>
>> I tried with Debian Squeeze with the latest backports kernel 2.6.38,
>> which has mpt2sas version 07.100.00.00
>> and now the disks are ordered this way:
>>
>> /dev/sdb = slot 3
>> /dev/sdc = slot 2
>> /dev/sdd = slot 1
>> /dev/sde = slot 0
>> /dev/sdf = slot 7
>> /dev/sdg = slot 6
>> /dev/sdh = slot 5
>> /dev/sdi = slot 4
>>
>> So there's more consistency here but still ordered backwards (per port)
>>
>> Kind regards,
>>
>> Caspar Smit
>>
>>
>> 2011/5/13 Caspar Smit <c.smit@truebit.nl>:
>> > Hi all,
>> >
>> > I'm having a minor issue with the disk ordering using an LSI 9211-8i
>> > (mpt2sas) controller.
>> >
>> > If i go into the controllers SAS config utility during boot I can
>> > identify the disks in the slots.
>> >
>> > disk 0 -> slot 0, disk 1 -> slot 1, etc.. everyhting is fine.
>> >
>> > When I boot into debian linux lenny (using the latest backports
>> > 2.6.32-31 kernel, this kernel has version 02.100.03.00 of the mpt2sas
>> > driver)
>> >
>> > The disks are ordered this way:
>> >
>> > /dev/sda = internal SSD connected to the MB
>> >
>> > /dev/sdb = slot 0
>> > /dev/sdc = slot 1
>> > /dev/sdd = slot 2
>> > /dev/sde = slot 3
>> > /dev/sdf = slot 7 (!)
>> > /dev/sdg = slot 4
>> > /dev/sdh = slot 5
>> > /dev/sdi = slot 6
>> >
>> > So it seems the first 4 disks connected to SAS port 1 are ordered
>> > correctly and the last 4 disks are not.
>> >
>> > When I check /dev/disk/by-path i see the following:
>> >
>> > lrwxrwxrwx 1 root root 9 2011-05-13 10:52 pci-0000:04:00.0-sas-
>> > 0x500605b001d161b0:1:0-0x4433221103000000:0 -> ../../sdb
>> > lrwxrwxrwx 1 root root 9 2011-05-13 10:52
>> > pci-0000:04:00.0-sas-0x500605b001d161b0:1:1-0x4433221102000000:0 ->
>> > ../../sdc
>> > lrwxrwxrwx 1 root root 9 2011-05-13 10:52
>> > pci-0000:04:00.0-sas-0x500605b001d161b0:1:2-0x4433221101000000:0 ->
>> > ../../sdd
>> > lrwxrwxrwx 1 root root 9 2011-05-13 10:52
>> > pci-0000:04:00.0-sas-0x500605b001d161b0:1:3-0x4433221100000000:0 ->
>> > ../../sde
>> > lrwxrwxrwx 1 root root 9 2011-05-13 10:52
>> > pci-0000:04:00.0-sas-0x500605b001d161b0:1:4-0x4433221104000000:0 ->
>> > ../../sdf
>> > lrwxrwxrwx 1 root root 9 2011-05-13 10:52
>> > pci-0000:04:00.0-sas-0x500605b001d161b0:1:5-0x4433221107000000:0 ->
>> > ../../sdg
>> > lrwxrwxrwx 1 root root 9 2011-05-13 10:52
>> > pci-0000:04:00.0-sas-0x500605b001d161b0:1:6-0x4433221106000000:0 ->
>> > ../../sdh
>> > lrwxrwxrwx 1 root root 9 2011-05-13 10:52
>> > pci-0000:04:00.0-sas-0x500605b001d161b0:1:7-0x4433221105000000:0 ->
>> > ../../sdi
>> >
>> > This LOOKS as it should but right now it is not really correct
>> because
>> > 1:7 indicates that it should be physical slot 7 (sdi is in slot 6 and
>> > not in slot 7)
>> >
>> > When i use the sas2ircu command line util to LOCATE the disks and I
>> > use 1:7 to locate, slot 7 lights up (NOT disk sdi)
>> >
>> > Is this behavior fixed in a newer version of the driver, and if so
>> > what is the corresponding patch to fix this?
>> >
>> > Kind regards,
>> >
>> > Caspar Smit
>> >
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-scsi"
>> in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-05-13 12:05 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-13 9:19 mpt2sas: bug in disk ordering? Caspar Smit
2011-05-13 10:34 ` Caspar Smit
2011-05-13 10:37 ` Arne Jansen
2011-05-13 10:41 ` Caspar Smit
2011-05-13 10:51 ` Arne Jansen
2011-05-13 10:56 ` Caspar Smit
2011-05-13 11:15 ` Desai, Kashyap
2011-05-13 11:46 ` Caspar Smit
2011-05-13 12:03 ` Billy Crook
2011-05-13 12:05 ` Caspar Smit [this message]
2011-05-13 12:09 ` Mikael Abrahamsson
2011-05-13 14:39 ` James Bottomley
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=BANLkTinqCmZzc2E7G1-W0qB-p8domw4KYA@mail.gmail.com \
--to=c.smit@truebit.nl \
--cc=Eric.Moore@lsi.com \
--cc=Kashyap.Desai@lsi.com \
--cc=Sathya.Prakash@lsi.com \
--cc=linux-scsi@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).