Allow pool names that look like Solaris disk names

[ghost]

Motivation and Context

Nothing bad happens if a prefix of your pool name matches a disk name.
This is a bit of a silly restriction at this point.

Fixes #11781

Description

Remove pool name check for Solaris disk-like prefix.

How Has This Been Tested?

Tested by reporter of #11781

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[behlendorf]

Wouldn't this still lead to problems if someone tried to import the pool on illumos?

[ikozhukhov]

i do not approve it because it can lead issue on DilOS
can we discuss it first for compatibility and transparent import between platforms ?

[ghost]

@ikozhukhov could you explain what is the issue it causes? From what I can tell it is only enforced for cosmetics.

[ikozhukhov]

easy explain by example where you can find VDEV name format.

root@zfs-t1:~# diskinfo
TYPE    DISK                                   VID      PID              SIZE            RMV SSD
SCSI    c0t600144F08844C0490000605C7CF20001d0  XDSK     XLUN             8G              no  no
SCSI    c0t600144F08844C0490000605C7D000002d0  XDSK     XLUN             8G              no  no
SCSI    c0t600144F08844C0490000605C7D150003d0  XDSK     XLUN             8G              no  no
SCSI    c0t600144F08844C0490000605C7D6C0004d0  XDSK     XLUN             8G              no  no
SCSI    c0t600144F08844C0490000605C7D7A0005d0  XDSK     XLUN             8G              no  no
SCSI    c0t600144F08844C0490000605C7D840006d0  XDSK     XLUN             8G              no  no
SCSI    c0t600144F08844C0490000605C7D950007d0  XDSK     XLUN             8G              no  no
SCSI    c0t600144F08844C0490000605C7DA10008d0  XDSK     XLUN             8G              no  no
SCSI    c0t600144F08844C0490000605C7DAB0009d0  XDSK     XLUN             8G              no  no
SCSI    c0t600144F08844C0490000605C7DB6000Ad0  XDSK     XLUN             8G              no  no
SCSI    c0t600144F08844C0490000605C7DC0000Bd0  XDSK     XLUN             8G              no  no
SCSI    c0t600144F08844C0490000605C7DC9000Cd0  XDSK     XLUN             8G              no  no
SATA    c1t1d0                                 VMware   Virtual SATA Ha> 40G             no  no
SATA    c1t2d0                                 VMware   Virtual SATA Ha> 8G              no  no
SATA    c1t3d0                                 VMware   Virtual SATA Ha> 8G              no  no
SATA    c1t4d0                                 VMware   Virtual SATA Ha> 8G              no  no
SATA    c1t5d0                                 VMware   Virtual SATA Ha> 10G             no  no

root@zfs-t1:~# zpool create -f c1t4d0 c1t4d0
cannot create 'c1t4d0': pool name is reserved
pool name may have been omitted

[ghost]

I can see it being a way to help prevent a user from accidentally creating a pool without specifying a pool name. If you patch out the check on DilOS and create a pool with a disklike name, does anything actually break?

[ikozhukhov]

it will be really confusion of users where you want offline/add/remove/online vdev:
zpool add c1t4d0 c1t4d0
how you think it can work and described in docs ?

[ghost]

It wouldn't be any more confusing than if someone named their pool md0 or ada0 or da0 on FreeBSD or sda1 on Linux, which is currently possible. The issue is really that this check is overly simplistic and fails to serve its purpose on the majority of platforms. A proper device name check could be put here for each platform to implement appropriately, but as currently implemented this check is preventing perfectly reasonable pool names from being used.

[ikozhukhov]

will be much more better do not allow these pool names on all platforms where we are using OpenZFS for reduce confusions between imports of pools.
you can extend checks and propagate it to know FreeBSD and Linux platforms too.
it's my opinion

[gmelikov]

@freqlabs sorry if I confused you with my thumbs up, I wanted to agree that we don't restrict any Linux/FreeBSD names and don't have any problem now, so I'm all for this PR.

[ghost]

I prefer this approach.

[behlendorf]

This seems preferable to me as well. Particularly because on Linux with the /dev/disk/by-vdev/ paths there are no restrictions on what you can name a disk. I could see an argument for issuing a warning at create time when creating a pool with one of these names, but I don't think it should be fatal. This kind of thing has always been allowed on Linux and to my knowledge it's never really been an issue.

[gmelikov]

LGTM, we may clean up other NAME_ERR_DISKLIKE parts later.

[behlendorf]

There's some value in keeping the NAME_ERR_DISKLIKE part if we were to instead treat this as a warning at pool creation time and not an error.

[ghost]

Keeping NAME_ERR_DISKLIKE in libzfs also ensures userland will understand it on an older module, but my main motivation for leaving it in was to avoid breaking the libzfs ABI.