All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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: link
Be 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.