public inbox for linux-block@vger.kernel.org
 help / color / mirror / Atom feed
From: Simon Kirby <sim@hostway.ca>
To: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Cc: linux-scsi@vger.kernel.org, linux-block@vger.kernel.org
Subject: Re: Unreliable disk detection order in 5.x
Date: Sat, 6 Nov 2021 19:24:10 -0700	[thread overview]
Message-ID: <20211107022410.GA6530@hostway.ca> (raw)
In-Reply-To: <9c14628f-4d23-dedf-3cdc-4b4266d5a694@opensource.wdc.com>

On Fri, Nov 05, 2021 at 04:45:53PM +0900, Damien Le Moal wrote:

> > Any ideas on suggestions on what I could use to track down what changed
> > here, or ideas on what might have influenced it?
> 
> Most distro kernels are now compiled with asynchronous device scan enabled to
> speedup the boot process. This potentially result in the device names changing
> across reboots. Reliable device names are provided by udev under
> /dev/disk/by-id, by-uuid etc.
> 
> You can turn off scsi asynchronous device scan using the scsi_mod.scan=sync
> kernel boot argument, or disable the CONFIG_SCSI_SCAN_ASYNC option for your
> kernel (device drivers -> scsi device support -> asynchronous scsi scanning).
> 
> But even with synchronous scanning, device names are not reliable and there are
> no guarantees that one particular device will always have the same name.

This occurs regardless of the CONFIG_SCSI_SCAN_ASYNC setting, and also
with scsi_mod.scan=sync on vendor kernels. All of these disks are coming
from the same driver and card.

I understand that using UUIDs, by-id, etc., is an option to work around
this, but then we would have to push IDs for disks in every server to our
configuration management. It does not seem that this change is really
intentional.

Simon-

  reply	other threads:[~2021-11-07  2:24 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-05  6:46 Unreliable disk detection order in 5.x Simon Kirby
2021-11-05  7:45 ` Damien Le Moal
2021-11-07  2:24   ` Simon Kirby [this message]
2021-11-07 19:51     ` Bart Van Assche
2021-11-11  1:01       ` Simon Kirby
2021-11-11  1:16         ` Damien Le Moal
2021-11-11  6:57         ` Hannes Reinecke
2021-11-12  0:11           ` Phillip Susi
2021-11-12  6:38             ` Hannes Reinecke

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=20211107022410.GA6530@hostway.ca \
    --to=sim@hostway.ca \
    --cc=damien.lemoal@opensource.wdc.com \
    --cc=linux-block@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox