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
WARNING: multiple messages have this Message-ID (diff)
From: "Martin K. Petersen" <martin.petersen@oracle.com> To: Martin Wilck <martin.wilck@suse.com> Cc: Reinecke <hare@suse.com>, "jejb@linux.vnet.ibm.com" <jejb@linux.vnet.ibm.com>, "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>, "martin.petersen@oracle.com" <martin.petersen@oracle.com>, Hannes, "dm-devel@redhat.com" <dm-devel@redhat.com>, "dgilbert@interlog.com" <dgilbert@interlog.com>, "systemd-devel@lists.freedesktop.org" <systemd-devel@lists.freedesktop.org>, "hch@lst.de" <hch@lst.de> Subject: Re: [dm-devel] 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 -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
next prev parent reply other threads:[~2021-04-23 1:41 UTC|newest] Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-29 9:58 RFC: one more time: SCSI device identification Martin Wilck 2021-03-29 9:58 ` [dm-devel] " Martin Wilck 2021-04-06 4:47 ` Martin K. Petersen 2021-04-06 4:47 ` [dm-devel] " Martin K. Petersen 2021-04-16 23:28 ` Martin Wilck 2021-04-16 23:28 ` [dm-devel] " Martin Wilck 2021-04-22 2:46 ` Martin K. Petersen 2021-04-22 2:46 ` [dm-devel] " Martin K. Petersen 2021-04-22 9:07 ` Martin Wilck 2021-04-22 9:07 ` [dm-devel] " Martin Wilck 2021-04-22 16:14 ` Benjamin Marzinski 2021-04-22 16:14 ` [dm-devel] " Benjamin Marzinski 2021-04-23 1:40 ` Martin K. Petersen [this message] 2021-04-23 1:40 ` Martin K. Petersen 2021-04-23 10:28 ` Martin Wilck 2021-04-23 10:28 ` [dm-devel] " Martin Wilck 2021-04-26 11:14 ` Antw: [EXT] Re: [systemd-devel] " Ulrich Windl 2021-04-26 11:14 ` [dm-devel] " Ulrich Windl 2021-04-26 13:16 ` Martin Wilck 2021-04-26 13:16 ` [dm-devel] " Martin Wilck 2021-04-27 3:48 ` Erwin van Londen 2021-04-27 7:02 ` Antw: [EXT] " Ulrich Windl 2021-04-27 7:02 ` [dm-devel] Antw: [EXT] " Ulrich Windl 2021-04-27 8:10 ` [dm-devel] " Martin Wilck 2021-04-27 8:10 ` Martin Wilck 2021-04-27 8:21 ` Hannes Reinecke 2021-04-27 8:21 ` Hannes Reinecke 2021-04-27 10:52 ` Antw: [EXT] " Ulrich Windl 2021-04-27 10:52 ` [dm-devel] Antw: [EXT] " Ulrich Windl 2021-04-27 20:04 ` Antw: [EXT] Re: [dm-devel] " Ewan D. Milne 2021-04-27 20:04 ` [dm-devel] Antw: [EXT] " Ewan D. Milne 2021-05-04 7:32 ` Antw: [EXT] Re: [dm-devel] " Hannes Reinecke 2021-05-04 7:32 ` [dm-devel] Antw: [EXT] " Hannes Reinecke 2021-04-28 1:01 ` [dm-devel] " Erwin van Londen 2021-04-28 6:34 ` Martin Wilck 2021-04-28 6:34 ` Martin Wilck 2021-04-29 14:47 ` Erwin van Londen 2021-04-29 14:47 ` Erwin van Londen 2021-04-27 20:14 ` Ewan D. Milne 2021-04-27 20:14 ` [dm-devel] " Ewan D. Milne 2021-04-27 20:33 ` Martin Wilck 2021-04-27 20:33 ` [dm-devel] " Martin Wilck 2021-04-27 20:41 ` Ewan D. Milne 2021-04-27 20:41 ` [dm-devel] " Ewan D. Milne 2021-04-28 0:09 ` Erwin van Londen 2021-04-30 23:44 ` Ewan D. Milne 2021-05-03 2:34 ` Erwin van Londen 2021-05-03 2:34 ` Erwin van Londen 2021-04-28 6:30 ` [systemd-devel] " Martin Wilck 2021-04-28 6:30 ` [dm-devel] " Martin Wilck
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: linkBe 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.