-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
phase out zpool_id #981
Labels
Type: Documentation
Indicates a requested change to the documentation
Type: Feature
Feature request or new feature
Milestone
Comments
nedbass
added a commit
to nedbass/zfs
that referenced
this issue
Dec 3, 2012
Add a vdev_id feature to map device names based on already defined udev device links. To increase the odds that vdev_id will run after the rules it depends on, increase the vdev.rules rule number from 60 to 69. With this change, vdev_id now provides functionality analogous to zpool_id and zpool_layout, paving the way to retire those tools. A defined alias takes precedence over a topology-derived name, but the two naming methods can otherwise coexist. For example, one might name drives in a JBOD with the sas_direct topology while naming an internal L2ARC device with an alias. For example, the following lines in vdev_id.conf will result in the creation of links /dev/disk/by-vdev/{d1,d2}, each pointing to the same target as the device link specified in the third field. # by-vdev # name fully qualified or base name of device link alias d1 /dev/disk/by-id/wwn-0x5000c5002de3b9ca alias d2 wwn-0x5000c5002def789e Also perform some minor vdev_id cleanup, such as removal of the unused -s command line option. Issue openzfs#981
behlendorf
added a commit
that referenced
this issue
Jan 29, 2013
In the interest of maintaining only one udev helper to give vdevs user friendly names, the zpool_id and zpool_layout infrastructure is being retired. They are superseded by vdev_id which incorporates all the previous functionality. Documentation for the new vdev_id(8) helper and its configuration file, vdev_id.conf(5), can be found in their respective man pages. Several useful example files are installed under /etc/zfs/. /etc/zfs/vdev_id.conf.alias.example /etc/zfs/vdev_id.conf.multipath.example /etc/zfs/vdev_id.conf.sas_direct.example /etc/zfs/vdev_id.conf.sas_switch.example Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #981
unya
pushed a commit
to unya/zfs
that referenced
this issue
Dec 13, 2013
Add a vdev_id feature to map device names based on already defined udev device links. To increase the odds that vdev_id will run after the rules it depends on, increase the vdev.rules rule number from 60 to 69. With this change, vdev_id now provides functionality analogous to zpool_id and zpool_layout, paving the way to retire those tools. A defined alias takes precedence over a topology-derived name, but the two naming methods can otherwise coexist. For example, one might name drives in a JBOD with the sas_direct topology while naming an internal L2ARC device with an alias. For example, the following lines in vdev_id.conf will result in the creation of links /dev/disk/by-vdev/{d1,d2}, each pointing to the same target as the device link specified in the third field. # by-vdev # name fully qualified or base name of device link alias d1 /dev/disk/by-id/wwn-0x5000c5002de3b9ca alias d2 wwn-0x5000c5002def789e Also perform some minor vdev_id cleanup, such as removal of the unused -s command line option. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes openzfs#981
unya
pushed a commit
to unya/zfs
that referenced
this issue
Dec 13, 2013
In the interest of maintaining only one udev helper to give vdevs user friendly names, the zpool_id and zpool_layout infrastructure is being retired. They are superseded by vdev_id which incorporates all the previous functionality. Documentation for the new vdev_id(8) helper and its configuration file, vdev_id.conf(5), can be found in their respective man pages. Several useful example files are installed under /etc/zfs/. /etc/zfs/vdev_id.conf.alias.example /etc/zfs/vdev_id.conf.multipath.example /etc/zfs/vdev_id.conf.sas_direct.example /etc/zfs/vdev_id.conf.sas_switch.example Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes openzfs#981
pcd1193182
pushed a commit
to pcd1193182/zfs
that referenced
this issue
Sep 26, 2023
…s#981) Bumps [pin-project](https://github.com/taiki-e/pin-project) from 1.1.0 to 1.1.2. - [Release notes](https://github.com/taiki-e/pin-project/releases) - [Changelog](https://github.com/taiki-e/pin-project/blob/main/CHANGELOG.md) - [Commits](taiki-e/pin-project@v1.1.0...v1.1.2) --- updated-dependencies: - dependency-name: pin-project dependency-type: indirect update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Type: Documentation
Indicates a requested change to the documentation
Type: Feature
Feature request or new feature
It would be nice to have only one udev helper to handle giving vdevs user friendly names. Currently we have vdev_id and the older zpool_id. This issue is to track incorporating zpool_id functionality into vdev_id so we can retire the former. zpool_id takes input from a file zdev.conf with lines of the form
where
name
is the name to give a disk for which udev's path_id helper producespath
. I would like to support a zdev.conf-like syntax in vdev_id.conf, along with a new "topology" type, saytopology explicit
. The syntax can't be supported directly, sincename
is an arbitrary string that may conflict with a vdev_id.conf keyword. Therefore I propose a new vdev_id.conf keyword, sayalias
, to prefix zdev.conf-like lines, i.e.By default, we would use path_id to generate the string to match. However, to be as generic as possible, we should allow an arbitrary helper to be specified, so users could use names from any of /dev/disk/by-{path,id,uuid,...}
The text was updated successfully, but these errors were encountered: