From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Martin Wilck <martin.wilck@suse.com>
Cc: "martin.petersen@oracle.com" <martin.petersen@oracle.com>,
Hannes Reinecke <hare@suse.com>, "hch@lst.de" <hch@lst.de>,
"dgilbert@interlog.com" <dgilbert@interlog.com>,
"dm-devel@redhat.com" <dm-devel@redhat.com>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"jejb@linux.vnet.ibm.com" <jejb@linux.vnet.ibm.com>,
"systemd-devel@lists.freedesktop.org"
<systemd-devel@lists.freedesktop.org>,
"bmarzins@redhat.com" <bmarzins@redhat.com>
Subject: Re: RFC: one more time: SCSI device identification
Date: Wed, 21 Apr 2021 22:46:27 -0400 [thread overview]
Message-ID: <yq1pmynt6f6.fsf@ca-mkp.ca.oracle.com> (raw)
In-Reply-To: <06489ea37311fe7bf73b27a41b5209ee4cca85fe.camel@suse.com> (Martin Wilck's message of "Fri, 16 Apr 2021 23:28:50 +0000")
Martin,
> Hm, it sounds intriguing, but it has issues in its own right. For
> years to come, user space will have to probe whether these attribute
> exist, and fall back to the current ones ("wwid", "vpd_pg83")
> otherwise. So user space can't be simplified any time soon. Speaking
> for an important user space consumer of WWIDs (multipathd), I doubt
> that this would improve matters for us. We'd be happy if the kernel
> could just pick the "best" designator for us. But I understand that
> the kernel can't guarantee a good choice (user space can't either).
But user space can be adapted at runtime to pick one designator over the
other (ha!).
We could do that in the kernel too, of course, but I'm afraid what the
resulting BLIST changes would end up looking like over time.
I am also very concerned about changing what the kernel currently
exports in a given variable like "wwid". A seemingly innocuous change to
the reported value could lead to a system no longer booting after
updating the kernel.
(Ignoring for a moment that some arrays will helpfully add a new ID
designator after a firmware upgrade and thus change what the kernel
reports. *sigh*)
> What is your idea how these new sysfs attributes should be named? Just
> enumerate, or name them by type somehow?
Up to you. Whatever you think would be easiest for userland to deal
with. I don't have a good feeling for how common vendor specific ones
are in practice. Things would obviously be easier if SCSI didn't have so
many choices :(
But taking a step back: Other than "it's not what userland currently
does", what specifically is the problem with designator_prio()? We've
picked the priority list once and for all. If we promise never to change
it, what is the issue?
--
Martin K. Petersen Oracle Linux Engineering
next prev parent reply other threads:[~2021-04-22 2:46 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-29 9:58 RFC: one more time: SCSI device identification Martin Wilck
2021-04-06 4:47 ` Martin K. Petersen
2021-04-16 23:28 ` Martin Wilck
2021-04-22 2:46 ` Martin K. Petersen [this message]
2021-04-22 9:07 ` Martin Wilck
2021-04-22 16:14 ` Benjamin Marzinski
2021-04-23 1:40 ` Martin K. Petersen
2021-04-23 10:28 ` Martin Wilck
2021-04-26 11:14 ` Antw: [EXT] Re: [systemd-devel] " Ulrich Windl
2021-04-26 13:16 ` Martin Wilck
[not found] ` <b5f288fb43bc79e0206794a901aef5b1761813de.camel@erwinvanlonden.net>
2021-04-27 7:02 ` Antw: [EXT] Re: [dm-devel] " Ulrich Windl
2021-04-27 8:10 ` Martin Wilck
2021-04-27 8:21 ` Hannes Reinecke
2021-04-27 10:52 ` Antw: [EXT] " Ulrich Windl
2021-04-27 20:04 ` Ewan D. Milne
2021-05-04 7:32 ` Hannes Reinecke
[not found] ` <ff5b30ca02ecfad00097ad5f8b84d053514fb61c.camel@erwinvanlonden.net>
2021-04-28 6:34 ` Martin Wilck
2021-04-29 14:47 ` Erwin van Londen
2021-04-27 20:14 ` Ewan D. Milne
2021-04-27 20:33 ` Martin Wilck
2021-04-27 20:41 ` Ewan D. Milne
2021-04-28 6:30 ` [systemd-devel] " Martin Wilck
[not found] ` <455a6e5086831323af86a150d21d5a0a7c2299eb.camel@erwinvanlonden.net>
[not found] ` <ba1ed6166b285d4ccb90f5f17b971983092d382e.camel@redhat.com>
2021-05-03 2:34 ` [dm-devel] " Erwin van Londen
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=yq1pmynt6f6.fsf@ca-mkp.ca.oracle.com \
--to=martin.petersen@oracle.com \
--cc=bmarzins@redhat.com \
--cc=dgilbert@interlog.com \
--cc=dm-devel@redhat.com \
--cc=hare@suse.com \
--cc=hch@lst.de \
--cc=jejb@linux.vnet.ibm.com \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.wilck@suse.com \
--cc=systemd-devel@lists.freedesktop.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