[systemd-devel] Bug? /dev/disk/by-path symlinks disappear, > for iSCSI targets

[Lee Duncan]

On 10/12/2014 12:00 PM, Kay Sievers <kay at vrfy.org> wrote:
> 
> On Tue, Oct 7, 2014 at 6:21 PM, Lee Duncan <lduncan at suse.com> wrote:
>> > I am debugging a problem where the symlinks in /dev/disk/by-path
>> > disappeared for iSCSI target devices.
>> >
>> > It looks like it's from systemd/udev commit
>> > e98bbfd2074e2b1079b7059341eac25741baf319
>> >
>> >  udev: path_id - suppress ID_PATH for devices with an unknown parent device type
>> >
>> > I believe the worry was that if you allowed pathnames based on a
>> > parent bus that did not supply unique IDs, then you could end up with
>> > duplicate paths, since this references a bug:
>> >
>> >     https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1321816
>> >
>> > But, looking at the code, this change seems to have assumed SCSI was
>> > not a "supported parent". I am not aware of any cases where SCSI has
>> > given duplicate names to devices
> It is not about non-conflicting numbers, it is about predictability of
> the numbers. The SCSI enumeration numbers are not predictable and
> depend on enumeration or discovery order. The numbers used in by-path
> links would need to be able to be calculated before the device is
> connected.

I'm not sure why you want to calculate a link before it's needed, but it
seems like it certainly could be done here.

The formulate for iSCSI links seems to be:

   ip-<IP_ADDR>:<PORT>-iscsi-<IQN>-iscsi-lun-<LUN#>-part<PART#>

> 
> The by-path links with non-predictable numbers are pointless and wrong
> to create.

I'm not sure what you think the by-path links are for, but they
certainly aren't pointless. How do you reach that conclusion?

> It is expected that only a very limited subset of devices
> support by-path, there is nothing wrong if iSCSI does not have them.

That is just not the case, and stating that it is the case doesn't make
it so.

There are lots of regular folks out there that use the by-path links,
and no bug report that I know of ever complained of them causing any
problems. Just because they fail some (arbitrary) purity test doesn't
mean they are useless.

> 
> While we are at it: all specialized SCSI code should move to its own
> package and out of the systemd/udev source tree. We will not extend
> any SCSI handling in udev, we just cannot support it. Hannes already
> started to work on moving things to sg3_utils. Hannes, any update on
> this?

How about if we use the path_id program and drop the now-broken built-in
version?

> 
> Thanks,
> Kay
> 

No, thank you.
-- 
Lee Duncan
SUSE Labs