Page MenuHomeFreeBSD

Rationalize SES physical paths strings and device aliases
Needs ReviewPublic

Authored by asomers on Mar 17 2023, 1:50 AM.
Tags
None
Referenced Files
Unknown Object (File)
Oct 1 2024, 11:01 AM
Unknown Object (File)
Sep 23 2024, 7:06 PM
Unknown Object (File)
Sep 23 2024, 7:06 PM
Unknown Object (File)
Sep 23 2024, 6:57 PM
Unknown Object (File)
Sep 5 2024, 4:41 AM
Unknown Object (File)
Aug 18 2024, 5:57 AM
Unknown Object (File)
Jul 23 2024, 9:19 AM
Unknown Object (File)
Jul 15 2024, 12:06 AM
Subscribers

Details

Reviewers
ken
mav
Group Reviewers
cam
Summary

In physical path strings:

  • Eliminate the curious "n" character before the SEP's addressed logical unit WWN.
  • Eliminate the unnecessary elmdesc@ component
  • Change the type@X component, which used a vendor-specific type_index, to a vendor-independent "elmtype@S", where S is a human-readable string like "array_device".
  • Change the slot number from hexadecimal to decimal.

In physical path device aliases:

  • Change the physical path device aliases from using full device names to using just the driver name. For example, from "/dev/$PHYSPATH/da40" to "/dev/$PHYSPATH/da". This allows you to open a device if you only know its physical path and not its unit number. Unfortunately, some GEOM transforms may allow multiple providers to share the same physical path. As of this change, only one of them can claim the physical path device node alias.

These changes make the physical paths more useful, and also reduce the
incidence of annoying "WARNING: Unable to alias foo to bar - path too
long" errors on boot, since the physical path device node aliases get
shorter.

Sponsored by: Spectra Logic, Axcient

Test Plan

Manually tested

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 50438
Build 47329: arc lint + arc unit

Event Timeline

The original physical path format came from Solaris/Illumos. While I agree that it is ugly and not very documented, I am not a big fan of incompatible changes. I'd think twice.

About the second part, there are dual-actuator HDDs providing two LUNs, in which case there will be two different da devices with the same physical path, and it is valid, unless we concatenate a LUN number or something to the path. Otherwise I agree that it would be convenient.

In D39141#891271, @mav wrote:

The original physical path format came from Solaris/Illumos. While I agree that it is ugly and not very documented, I am not a big fan of incompatible changes. I'd think twice.

I'm only aware of two potential problems with breaking backwards compatibility:

  • If somebody is using the /dev/enc@... device alias in /etc/fstab. They'll have to update that by hand.
  • If somebody has a ZFS pool with a missing device at the time they apply this update, then zfsd won't autoreplace the missing disk when it arrives. But they'll still be able to replace it by hand.

I suspect that neither case is common, and IMHO the one-time backwards compatibility break is worthwhile, in exchange for getting physical paths that actually mean something. Shall we take it to the mailing list to get more opinions?

About the second part, there are dual-actuator HDDs providing two LUNs, in which case there will be two different da devices with the same physical path, and it is valid, unless we concatenate a LUN number or something to the path. Otherwise I agree that it would be convenient.

That's a good reason to add the LUN number. zfsd will try to autoreplace disks by physical path, and we don't want it to grab the wrong actuator.

@mav do you have any of those dual-actuator HDDs? If so, would you be willing to test a patch that adds their LUN numbers to the physical path string? I can send that separately.

@mav do you have any of those dual-actuator HDDs? If so, would you be willing to test a patch that adds their LUN numbers to the physical path string? I can send that separately.

I have couple of those in my office desk, but tomorrow morning I am leaving for AsiaBSDCon and will be back only after April 10.

In D39141#894562, @mav wrote:

@mav do you have any of those dual-actuator HDDs? If so, would you be willing to test a patch that adds their LUN numbers to the physical path string? I can send that separately.

I have couple of those in my office desk, but tomorrow morning I am leaving for AsiaBSDCon and will be back only after April 10.

Ok. How about we merge this PR now, and I'll have a new one ready for you to test when you get back from Asia?

Ok. How about we merge this PR now, and I'll have a new one ready for you to test when you get back from Asia?

As I have told above, I am concerned about the change in phys path format. But I haven't put too much thinking into it after. I won't object beyond that, but some wider discussion may be good.

UPDATING
37

one thing that might be useful is an example before/after path