Re: [systemd-devel] RFC: one more time: SCSI device identification
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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: one more time: SCSI device identification
Martin,
> 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).
But user space can be adapted at runtime to pick one designator over the
other (ha!).
We could do that in the kernel too, of course, but I'm afraid what the
resulting BLIST changes would end up looking like over time.
I am also very concerned about changing what the kernel currently
exports in a given variable like "wwid". A seemingly innocuous change to
the reported value could lead to a system no longer booting after
updating the kernel.
(Ignoring for a moment that some arrays will helpfully add a new ID
designator after a firmware upgrade and thus change what the kernel
reports. *sigh*)
> What is your idea how these new sysfs attributes should be named? Just
> enumerate, or name them by type somehow?
Up to you. Whatever you think would be easiest for userland to deal
with. I don't have a good feeling for how common vendor specific ones
are in practice. Things would obviously be easier if SCSI didn't have so
many choices :(
But taking a step back: Other than "it's not what userland currently
does", what specifically is the problem with designator_prio()? We've
picked the priority list once and for all. If we promise never to change
it, what is the issue?
--
Martin K. Petersen Oracle Linux Engineering
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: one more time: SCSI device identification
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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
