All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Keith Busch <kbusch@kernel.org>
Cc: John Meneghini <jmeneghi@redhat.com>,
	"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>
Subject: Re: nvme/pcie hot plug results in /dev name change
Date: Fri, 20 Jan 2023 23:01:53 -0800	[thread overview]
Message-ID: <Y8uN4V8uW2qS+xHR@infradead.org> (raw)
In-Reply-To: <Y8sKv7q+UEbz5ddD@kbusch-mbp.dhcp.thefacebook.com>

On Fri, Jan 20, 2023 at 02:42:23PM -0700, Keith Busch wrote:
> That is correct. We don't know the identity of the device at the point
> we have to assign it an instance number, so the hot added one will just
> get the first available unique number. If you need a consistent name, we
> have the persistent naming rules that should create those links in
> /dev/disk/by-id/.

Note that this a bit of a problem under a file system or stacking driver
that handles failing drives (e.g. btrfs or md raid), that holds ontop
the "old" device file, and then fails to find the new one.  I had a
customer complaint for that as well :)

The first hack was to force run the multipath code that can keep the
node alive.  That works, but is really ugly especially when dealing
with corner cases such as overlapping nsids between different
controllers.

In the long run I think we'll need to:
 - send a notification to the holder if a device is hot removed from
   the block layer so that it can clean up
 - make the upper layers look for the replugged devie

I've been working on some of this for a while but haven't made much
progress due to other committments.


  reply	other threads:[~2023-01-21  7:02 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-20 19:50 nvme/pcie hot plug results in /dev name change John Meneghini
2023-01-20 21:42 ` Keith Busch
2023-01-21  7:01   ` Christoph Hellwig [this message]
2023-01-29 10:28     ` Ming Lei
2023-01-31 16:38       ` Keith Busch
2023-02-01  2:33         ` Ming Lei
2023-02-01  6:27           ` Christoph Hellwig
2023-02-01 16:31             ` Keith Busch
2023-02-13 14:01               ` Sagi Grimberg
2023-02-13 16:32                 ` Keith Busch
2023-02-14  0:04                   ` Ming Lei
2023-02-14  9:18                     ` Sagi Grimberg
2023-02-15  1:04                       ` Ming Lei
2023-02-14 16:17                     ` Keith Busch
2023-02-15  1:11                       ` Ming Lei
2023-02-14  9:04                   ` Sagi Grimberg
2023-02-15  6:18                   ` Christoph Hellwig
2023-02-15  8:56                     ` Sagi Grimberg
2023-02-15 22:18             ` Keith Busch

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=Y8uN4V8uW2qS+xHR@infradead.org \
    --to=hch@infradead.org \
    --cc=jmeneghi@redhat.com \
    --cc=kbusch@kernel.org \
    --cc=linux-nvme@lists.infradead.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.