All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Snitzer <snitzer@kernel.org>
To: Benjamin Coddington <bcodding@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>, Alasdair Kergon <agk@redhat.com>,
	Mikulas Patocka <mpatocka@redhat.com>,
	dm-devel@lists.linux.dev, linux-nfs@vger.kernel.org
Subject: Re: dm: add support for get_unique_id
Date: Wed, 30 Oct 2024 10:24:11 -0400	[thread overview]
Message-ID: <ZyJBi68xWvTgUV5g@kernel.org> (raw)
In-Reply-To: <313BC47B-6069-4AB4-BD44-F71461726F8B@redhat.com>

On Wed, Oct 30, 2024 at 10:19:11AM -0400, Benjamin Coddington wrote:
> On 30 Oct 2024, at 10:08, Christoph Hellwig wrote:
> 
> > On Wed, Oct 30, 2024 at 10:05:03AM -0400, Benjamin Coddington wrote:
> >> Match each other in a multipath device you mean?  No, this will just return
> >> the first one where get_unique_id returns non-zero.  Can they actually be
> >> different, and if so should we return an error?
> >
> > That's what I've been wondering.  IIRC you can in theory create a
> > kernel mpath table for any devices you want.  multipathd only creates
> > them when the ids match, but do we want to rely on that?  It might be
> > perfectly fine to say if you break you keep the pieces, but then
> > I'd expected a comment about it in the comment.
> 
> Comment is easier than comparing them all, I'm happy to add it.  Seems like
> a mpath table with different devices would make little pieces of anything
> you try to put on it, and you wouldn't even get to keep those pieces.
> 
> Maybe other dm experts can think of ways that might break things.. I'll wait
> a day or so.

It would be a concern for multipathd, you don't need to worry about this.

Documenting that dm_blk_get_unique_id returns the uuid from the
first underlying device that supports ->get_unique_id should be
sufficient.

Mike

      reply	other threads:[~2024-10-30 14:24 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-30 12:57 [PATCH] dm: add support for get_unique_id Benjamin Coddington
2024-10-30 13:52 ` Christoph Hellwig
2024-10-30 14:05   ` Benjamin Coddington
2024-10-30 14:08     ` Christoph Hellwig
2024-10-30 14:19       ` Benjamin Coddington
2024-10-30 14:24         ` Mike Snitzer [this message]

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=ZyJBi68xWvTgUV5g@kernel.org \
    --to=snitzer@kernel.org \
    --cc=agk@redhat.com \
    --cc=bcodding@redhat.com \
    --cc=dm-devel@lists.linux.dev \
    --cc=hch@lst.de \
    --cc=linux-nfs@vger.kernel.org \
    --cc=mpatocka@redhat.com \
    /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.