From: Boaz Harrosh <bharrosh@panasas.com>
To: david@lang.hm
Cc: linux-kernel <linux-kernel@vger.kernel.org>, linux-scsi@vger.kernel.org
Subject: Re: deterministic scsi order with async scan
Date: Thu, 16 Jul 2009 22:53:46 +0300 [thread overview]
Message-ID: <4A5F854A.7030101@panasas.com> (raw)
In-Reply-To: <alpine.DEB.1.10.0907161017180.9159@asgard>
On 07/16/2009 08:22 PM, david@lang.hm wrote:
> On Thu, 16 Jul 2009, Boaz Harrosh wrote:
>
>> On 07/16/2009 04:09 AM, david@lang.hm wrote:
>>> is there any way to get deterministic device ordering with scsi async
>>> scanning?
>>>
>>> currently (2.6.30) it seems that the various scsi busses are loaded in the
>>> order that they are detected, which can vary from boot to boot depending
>>> on how long it takes for the card to initialize.
>>>
>>> would it be possible to detect the cards/drives, but not register them
>>> until all the detection is complete so that they can be registered in a
>>> deterministic order?
>>>
>>> having two drives on two different controllers swap positions from boot to
>>> boot makes it very painful. yes I can make an initrd that fixes this up in
>>> user space by examining each drive and creating links to re-order them,
>>> but this is a lot of work to fix randomization that can be prevented in
>>> the first place.
>>>
>>> David Lang
>> It is highly discouraged to setup any kind of system that depends
>> on device-names for block-devices. mounts have the mount by-label
>> or mount by-uuid. Any other subsystem should go by /dev/disk/by-id/*
>> slinks to find a persistent raw block-device. the id is generated
>> from characteristics inside the disk itself so it will be the same
>> no matter what host connection or bus it is connected too (almost).
>>
>> This is because even if the boot order is consistent, the device-name
>> is so volatile in the life-span of a system. Did I boot with a removable
>> USB inserted. that camera or printer was on or off, disk was connected
>> to the other port. Any such change will break things and give you a very
>> poor user experience.
>
> for a laptop you areprobably correct, but for a server or embedded system
> that doesn't have it's hardware changing all the time you are not correct.
>
> especially on a system with lots of drives, why should I have to create an
> initrd that goes and searches dozens or hundreds of drives to find out
> which one to boot from?
>
there is *no* searching with /dev/disk/by-id/ or /dev/disk/by-uuid/
Udev comes reads a small piece of information and puts up a link.
now: not(initrd+Udev) == Kernel_with_no_legs
> I am building a system that will have two drives in a hardware mirror on
> one SCSI card, and 160 drives on a FC (SCSI) card. why should my boot have
> to go and examine all 162 drives to look for an ID on every partition just
> to find the boot drive?
>
Again no searching is done here, just read of a sector for uuid and some
query command for by-id
>> I would say that "scsi async" is a grate blessing
>
> it's great for startup time, but doing the async detection doesn't
> _require_ doing async registration.
>
> David Lang
Boaz
next prev parent reply other threads:[~2009-07-16 19:53 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-16 1:09 deterministic scsi order with async scan david
2009-07-16 11:33 ` Boaz Harrosh
2009-07-16 17:22 ` david
2009-07-16 18:32 ` James Smart
2009-07-16 18:43 ` david
2009-07-16 19:39 ` James Bottomley
2009-07-16 19:48 ` david
2009-07-16 19:56 ` James Bottomley
2009-07-16 20:59 ` david
2009-07-16 19:58 ` Boaz Harrosh
2009-07-16 20:05 ` Matthew Wilcox
2009-07-16 19:53 ` Boaz Harrosh [this message]
2009-07-16 11:57 ` Matthew Wilcox
2009-07-16 17:23 ` david
2009-07-16 18:15 ` Matthew Wilcox
2009-07-16 18:31 ` david
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=4A5F854A.7030101@panasas.com \
--to=bharrosh@panasas.com \
--cc=david@lang.hm \
--cc=linux-kernel@vger.kernel.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.