import: add newname property to rename pool on next import

[robn]

Motivation and Context

Renaming a pool is possible by providing an additional argument to zpool import. This assumes that the operator is able to comfortably export and re-import the pool, which is generally not the case for root/boot pools.

Description

This adds a newname pseudo-property to the pool. If it exists at import time, it will be used to the name the pool. This allows the operator to set the new name ahead of the next export/import cycle (eg, before rebooting).

The old method of renaming the pool is still available, and takes precedence over the property. The property itself is cleared on every successful import, regardless of the name used. This is justified as a policy of "most recent name wins", but really is just to avoid surprising renames when the property is left set and forgotten.

Because the value is needed during import, the property is stored on the label rather than in the props ZAP.

TODO

• Consider where this is applied; might be better done entirely inside the module rather than in zpool/libzfs, because it changes the call sequence required a little.
• To that end, need to find what alternate pool-importing code does and expects (bootloaders etc)
• Understand ZFS_IMPORT_VERBATIM and make this work with it (this might be the FreeBSD answer to the above two)
• General concept and design review.

Demo: https://asciinema.org/a/Bg8SpYXDTSsekTdRB37dX1elO

Call for assistance: I probably won't take this further myself, at least not in the near future - it's just not a thing I need. If you're interested and are willing to do some of work to test and tell me how you think it should work (especially around the boot hookup), let me know!

How Has This Been Tested?

Prototype, so only light manual testing.

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.

[amotin]

Sounds like an interesting functionality, but I worry what side effects it might have. For example, what can be its inter-operation with bootfs property, since boot pool is likely is the most difficult case to rename.