From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Martin Wilck <martin.wilck@suse.com>
Cc: "hch@lst.de" <hch@lst.de>,
"jejb@linux.vnet.ibm.com" <jejb@linux.vnet.ibm.com>,
"bmarzins@redhat.com" <bmarzins@redhat.com>,
Hannes Reinecke <hare@suse.com>,
"martin.petersen@oracle.com" <martin.petersen@oracle.com>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"dgilbert@interlog.com" <dgilbert@interlog.com>,
"systemd-devel@lists.freedesktop.org"
<systemd-devel@lists.freedesktop.org>,
"dm-devel@redhat.com" <dm-devel@redhat.com>
Subject: Re: RFC: one more time: SCSI device identification
Date: Tue, 06 Apr 2021 00:47:17 -0400 [thread overview]
Message-ID: <yq135w4cam3.fsf@ca-mkp.ca.oracle.com> (raw)
In-Reply-To: <c524ce68d9a9582732db8350f8a1def461a1a847.camel@suse.com> (Martin Wilck's message of "Mon, 29 Mar 2021 09:58:49 +0000")
Martin,
> The kernel's preference for type 8 designators (see below) is in
> contrast with the established user space algorithms, which determine
> SCSI WWIDs on productive systems in practice. User space can try to
> adapt to the kernel logic, but it will necessarily be a slow and
> painful path if we want to avoid breaking user setups.
I was concerned when you changed the kernel prioritization a while back
and I still don't think that we should tweak that code any further.
If the kernel picks one ID over another, that should be for the kernel's
use. Letting the kernel decide which ID is best for userland is not a
good approach.
So while I originally liked the idea of exposing a transport and
protocol agnostic wwid for each block device, I think that all the
descriptors and ID formats available in both SCSI and NVMe have shown
that that approach is fraught with peril.
Descriptors that provide "good uniqueness" on one device may be a
completely sub-optimal choice for another (zero-padded values, full of
spaces, vendors getting things wrong in general).
So I think my inclination would be to leave the current wwid as-is to
avoid the risk of breaking things. And then export all ID descriptors
reported in sysfs. Even though vpd83 is already exported in its
entirety, I don't have any particular concerns about the individual
values being exported separately. That makes many userland things so
much easier. And I think the kernel is in a good position to disseminate
information reported by the hardware.
This puts the prioritization entirely in the distro/udev/scripting
domain. Taking the kernel out of the picture will make migration
easier. And it allows a user to pick their descriptor of choice should a
device report something completely unusable in type 8.
--
Martin K. Petersen Oracle Linux Engineering
next prev parent reply other threads:[~2021-04-06 4:48 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 [this message]
2021-04-16 23:28 ` Martin Wilck
2021-04-22 2:46 ` Martin K. Petersen
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=yq135w4cam3.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