From: Martin Wilck <martin.wilck@suse.com> To: "martin.petersen@oracle.com" <martin.petersen@oracle.com> Cc: 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: Fri, 16 Apr 2021 23:28:50 +0000 [thread overview] Message-ID: <06489ea37311fe7bf73b27a41b5209ee4cca85fe.camel@suse.com> (raw) In-Reply-To: <yq135w4cam3.fsf@ca-mkp.ca.oracle.com> Hello Martin, Sorry for the late response, still recovering from a week out of office. On Tue, 2021-04-06 at 00:47 -0400, Martin K. Petersen wrote: > > 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. Ok. > 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. Well, the kernel itself doesn't make any use of this property currently (and user space doesn't much either, afaik). > 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. 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). What is your idea how these new sysfs attributes should be named? Just enumerate, or name them by type somehow? Thanks, Martin -- Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107 SUSE Software Solutions Germany GmbH HRB 36809, AG Nürnberg GF: Felix Imendörffer
WARNING: multiple messages have this Message-ID (diff)
From: Martin Wilck <martin.wilck@suse.com> To: "martin.petersen@oracle.com" <martin.petersen@oracle.com> Cc: Hannes Reinecke <hare@suse.com>, "jejb@linux.vnet.ibm.com" <jejb@linux.vnet.ibm.com>, "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>, "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: Fri, 16 Apr 2021 23:28:50 +0000 [thread overview] Message-ID: <06489ea37311fe7bf73b27a41b5209ee4cca85fe.camel@suse.com> (raw) In-Reply-To: <yq135w4cam3.fsf@ca-mkp.ca.oracle.com> Hello Martin, Sorry for the late response, still recovering from a week out of office. On Tue, 2021-04-06 at 00:47 -0400, Martin K. Petersen wrote: > > 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. Ok. > 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. Well, the kernel itself doesn't make any use of this property currently (and user space doesn't much either, afaik). > 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. 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). What is your idea how these new sysfs attributes should be named? Just enumerate, or name them by type somehow? Thanks, Martin -- Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107 SUSE Software Solutions Germany GmbH HRB 36809, AG Nürnberg GF: Felix Imendörffer -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
next prev parent reply other threads:[~2021-04-16 23:28 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 [this message] 2021-04-16 23:28 ` 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 2021-04-23 1:40 ` [dm-devel] " 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=06489ea37311fe7bf73b27a41b5209ee4cca85fe.camel@suse.com \ --to=martin.wilck@suse.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.petersen@oracle.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.