To respond to a few of the points on this thread: 1. If we need finer granularity than Linux/illumos/FreeBSD/OSX/Windows (e.g. distribution vs operating system), it seems like that would fit into this proposal. E.g. Substitute distro for OS in the suffix. Are there specific examples of ways that different distros interpret the existing sharenfs property differently? E.g. bringing a pool between OmniOS and SmartOS gets different behavior of the sharenfs property?
2. The distinction between user properties and system properties is that ZFS (/sbin/zfs, etc) takes some action based on system properties (like sharenfs). If we were to "replace" sharenfs with user properties, that would mean removing the sharenfs property and all share processing from ZFS, and letting consumers (perhaps distros) implement their own sharing system based on user properties. It seems like this would require a ton of work to make it as easy to use as the current sharenfs property. 3. Handling backwards compatibility with existing pools seems important and potentially tricky. Maybe this would be a feature flag, and once it's enabled, the first time you "zfs set sharenfs", we remove the old "sharenfs" and set the OS-specific property (e.g. "sharenfs_illumos"). Code for getting sharenfs would check both the platform-specific and generic properties (and we should never have both set at the same time). --matt On Mon, Feb 25, 2019 at 9:43 PM George Wilson <[email protected]> wrote: > 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 <https://openzfs.topicbox.com/latest>* / openzfs-developer / see > discussions <https://openzfs.topicbox.com/groups/developer> + participants > <https://openzfs.topicbox.com/groups/developer/members> + delivery options > <https://openzfs.topicbox.com/groups/developer/subscription> Permalink > <https://openzfs.topicbox.com/groups/developer/T6b50d98b3cf62715-Mfaa3006a379f2c07eed0d10a> > ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/T6b50d98b3cf62715-Maab4e04fd4755c80f8ec359d Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
