A couple of months ago we discussed the issues surrounding zfs properties which have platform specific implementations. The example given was “sharenfs” which has platform-specific syntax and platform-specific implementations. Having platform-specific syntax for these types of properties means that importing pools across platforms can lead to unexpected behavior. In order to ensure cross platform safety, I would like to propose the concept of platform-specific properties.
Here are some high level goals: 1. Platform-specific properties are only processed on their respective platform. If a platform-specific property does not exist for the platform where the pool is imported then it’s treated as an unset property and the default setting is used. 2. Converting a property to a platform-specific property should not break existing scripts. Administrators may rely on property names, like sharenfs, so platform-specific properties should continue to use the same naming convention 3. Platforms should be able to read and set platform-specific properties for other platforms Proposed Implementation: To accomplish this, I propose that we introduce a property alias to our current property scheme. The “alias” would only exist if a property is a platform-specific property. Platform-specific properties would append the operating system name to the property. For example, “sharenfs_Linux”, “sharenfs_SunOS”, or “sharenfs_FreeBSD”. In the case of the “sharenfs” property, the alias would remain as “sharenfs” and the real property name would be “sharenfs_Linux”, for example. When a user wants to “get” the value of “sharenfs” the system will automatically map the property name to the platform-specific property. Administrators can use the alias or the real property name when setting or getting the property: # zfs set sharenfs=on tank (preferred) # zfs set sharenfs_Linux=on tank Both result in the “sharenfs_Linux” property being set to “on” on-disk. Reading a property does the reverse mapping, allowing users to get “sharenfs” without having to know about the underlying platform-specific name: # zfs get sharenfs tank NAME PROPERTY VALUE SOURCE tank sharenfs on default Having this mapping allows pools to safely import across platforms since only properties that exist for that platform will be read and evaluated. Administrators may also want the ability to set another platform’s property, so in those cases setting the real property name should be allowed: ZFS running on a Linux system: # zfs set sharenfs_SunOS=off tank # zfs get sharenfs tank NAME PROPERTY VALUE SOURCE tank sharenfs on default #zfs get sharenfs_SunOS tank NAME PROPERTY VALUE SOURCE tank sharenfs_SunOS on default How do people feel about this approach? If we are to adopt this model, then how should we handle converting existing properties to platform-specific properties? Feedback and suggestions are welcome. Thanks, George ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/T6b50d98b3cf62715-Mfaa3006a379f2c07eed0d10a Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
