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: Thu, 22 Apr 2021 21:40:03 -0400 [thread overview]
Message-ID: <yq1im4dre94.fsf@ca-mkp.ca.oracle.com> (raw)
In-Reply-To: <685c40341d2ddef2fe5a54dd656d10104b0c1bfa.camel@suse.com> (Martin Wilck's message of "Thu, 22 Apr 2021 09:07:15 +0000")
Martin,
> I suppose 99.9% of users never bother with customizing the udev rules.
Except for the other 99.9%, perhaps? :) We definitely have many users
that tweak udev storage rules for a variety of reasons. Including being
able to use RII for LUN naming purposes.
> But we can actually combine both approaches. If "wwid" yields a good
> value most of the time (which is true IMO), we could make user space
> rely on it by default, and make it possible to set an udev property
> (e.g. ENV{ID_LEGACY}="1") to tell udev rules to determine WWID
> differently. User-space apps like multipath could check the ID_LEGACY
> property to determine whether or not reading the "wwid" attribute would
> be consistent with udev. That would simplify matters a lot for us (Ben,
> do you agree?), without the need of adding endless BLIST entries.
That's fine with me.
> AFAICT, no major distribution uses "wwid" for this purpose (yet).
We definitely have users that currently rely on wwid, although probably
not through standard distro scripts.
> In a recent discussion with Hannes, the idea came up that the priority
> of "SCSI name string" designators should actually depend on their
> subtype. "naa." name strings should map to the respective NAA
> descriptors, and "eui.", likewise (only "iqn." descriptors have no
> binary counterpart; we thought they should rather be put below NAA,
> prio-wise).
I like what NVMe did wrt. to exporting eui, nguid, uuid separately from
the best-effort wwid. That's why I suggested separate sysfs files for
the various page 0x83 descriptors. I like the idea of being able to
explicitly ask for an eui if that's what I need. But that appears to be
somewhat orthogonal to your request.
> I wonder if you'd agree with a change made that way for "wwid". I
> suppose you don't. I'd then propose to add a new attribute following
> this logic. It could simply be an additional attribute with a different
> name. Or this new attribute could be a property of the block device
> rather than the SCSI device, like NVMe does it
> (/sys/block/nvme0n2/wwid).
That's fine. I am not a big fan of the idea that block/foo/wwid and
block/foo/device/wwid could end up being different. But I do think that
from a userland tooling perspective the consistency with NVMe is more
important.
--
Martin K. Petersen Oracle Linux Engineering
next prev parent reply other threads:[~2021-04-23 1:41 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
2021-04-22 9:07 ` Martin Wilck
2021-04-22 16:14 ` Benjamin Marzinski
2021-04-23 1:40 ` Martin K. Petersen [this message]
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=yq1im4dre94.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