From: Ric Wheeler <rwheeler@redhat.com>
To: James Bottomley <James.Bottomley@suse.de>
Cc: Greg KH <greg@kroah.com>,
linux-scsi@vger.kernel.org, kay.sievers@vrfy.org,
Tom Coughlan <coughlan@redhat.com>
Subject: Re: mpt2sas logged messages
Date: Tue, 18 Aug 2009 13:44:34 -0400 [thread overview]
Message-ID: <4A8AE882.7050105@redhat.com> (raw)
In-Reply-To: <1250611768.6971.6.camel@mulgrave.site>
On 08/18/2009 12:09 PM, James Bottomley wrote:
> On Tue, 2009-08-18 at 11:53 -0400, Ric Wheeler wrote:
>> On 08/18/2009 10:57 AM, Greg KH wrote:
>>> On Tue, Aug 18, 2009 at 09:59:56AM -0400, Ric Wheeler wrote:
>>>
>>>> On 08/18/2009 09:25 AM, Greg KH wrote:
>>>>
>>>>> On Tue, Aug 18, 2009 at 09:18:30AM -0400, Ric Wheeler wrote:
>>>>>
>>>>>> We have a new toy to test very large& slow storage with built up from 5
>>>>>> SAS expansion shelves (Promise Vtrak J-Class) with 60 S-ATA drives and
>>>>>> 16 SAS drives (the S-ATA drives each have a Promise Vtrak S-ATA MUX
>>>>>> adapter daughter card in the disk sled).
>>>>>>
>>>>>> The basic idea is to build a cheap& slow test bed for file& storage
>>>>>> system scalability. Collectively, we have about 120TB (raw) of capacity
>>>>>> to play with in one server.
>>>>>>
>>>>>> As we work through various issues, a couple of oddities popped out.
>>>>>>
>>>>>> The first is that udev grumbles during boot about "file name too long"
>>>>>> like the following:
>>>>>>
>>>>>> Aug 17 06:49:58 megadeth udevd-event[20447]: unable to create db file
>>>>>> '/dev/.udev/db/\x2fdevices\x2fpci0000:00\x2f0000:00:04.0\x2f0000:17:00.0\x2f0000:18:0a.0\x2f0000:1f:00.0\x2fhost11\x2fport-11:0\x2fexpander-11:0\x2fport-11:0:0\x2fexpander-11:1\x2fport-11:1:0\x2fexpander-11:2\x2fport-11:2:17\x2fexpander-11:3\x2fport-11:3:1\x2fend_device-11:3:1\x2fbsg\x2fend_device-11:3:1':
>>>>>> File name too long
>>>>>>
>>>>> Odd, what is the sysfs tree for this device? You have expanders
>>>>> attached to ports attached to expanders? How deep can you go?
>>>>>
>>>>> thanks,
>>>>>
>>>>> greg k-h
>>>>>
>>>> There are two dual-port SAS HBA's in the server that plug into the first of the
>>>> 5 SAS expansion shelves. Each shelf has two internal SAS loops and is daisy
>>>> chained to the next shelf.... This test is running with just the first 4
>>>> shelves active (although that fifth shelf is plugged in, just not used/active).
>>>>
>>>> Each of the 60 S-ATA disks sits behind a MUX card which lets it appear on both
>>>> loops.
>>>>
>>>> We could break up the shelves into two independent sets of devices which would
>>>> limit the tree depth.
>>>>
>>>> How can I get you the sysfs tree information in a useful way?
>>>>
>>> 'tree /sys/devices/'
>>> or
>>> 'find /sys/devices/'
>>> would be good.
>>>
>>> thanks,
>>>
>>> greg k-h
>>>
>>
>> Attached is the bzipped output from - the uncompressed output is quite
>> large. Note that this same server has CCIS controllers and fibre HBA's
>> as well,
>
> It's perfectly legal the way you have it, but I will say you have an
> inefficient configuration. The way a configuration like this is
> supposed to look is that there should be a fanout expander at the top
> going to the expander in each tray, for a routing depth of two for every
> device.
>
> The way you've got it: expander daisy chained off the next expander
> gives an unnecessary routing delay to the disks furthest away in the
> chain.
>
> James
I understand that this configuration is not optimal, but from what I saw with
some commercial arrays, this is not an uncommon config (up to 4 shelves) when
going for capacity over performance.
Do you have a particular SAS fanout expander in mind? I suppose that we could
always add more hba's as well which would have other benefits...
Thanks!
Ric
next prev parent reply other threads:[~2009-08-18 17:42 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-18 13:18 mpt2sas logged messages Ric Wheeler
2009-08-18 13:25 ` Greg KH
2009-08-18 13:55 ` James Bottomley
2009-08-18 13:59 ` Ric Wheeler
2009-08-18 14:57 ` Greg KH
2009-08-18 15:53 ` Ric Wheeler
2009-08-18 16:09 ` James Bottomley
2009-08-18 17:44 ` Ric Wheeler [this message]
2009-08-18 20:14 ` James Bottomley
2009-08-18 20:33 ` Ric Wheeler
2009-08-18 16:40 ` Greg KH
2009-08-18 17:45 ` Ric Wheeler
2009-08-18 18:37 ` Kay Sievers
2009-08-18 18:41 ` Ric Wheeler
2009-08-19 19:30 ` Kay Sievers
2009-08-19 19:36 ` Ric Wheeler
2009-08-20 15:18 ` Ric Wheeler
2009-08-20 15:20 ` Kay Sievers
2009-08-20 15:30 ` Ric Wheeler
2009-08-18 13:26 ` Ric Wheeler
2009-08-18 15:39 ` Moore, Eric
2009-08-18 16:13 ` James Bottomley
2009-08-18 17:02 ` Moore, Eric
2009-08-18 17:47 ` Ric Wheeler
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=4A8AE882.7050105@redhat.com \
--to=rwheeler@redhat.com \
--cc=James.Bottomley@suse.de \
--cc=coughlan@redhat.com \
--cc=greg@kroah.com \
--cc=kay.sievers@vrfy.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.