I suspect having the platform “resolve” which property to use is going to be problematic at the very best. The semantics are platform specific, and to make matters worse, I suspect that even on some platforms, you will find distributions that have imparted their own meanings to these properties. For example, I know of several different distributions built on illumos, and they don’t necessarily handle the properties in a perfectly compatible way. I suspect the situation may actually be worse on Linux, where some distributions are likely to ship with *wildly* different userland and system layers (e.g. systemd vs. legacy rc scripts), and may thus wind up having quite different supported properties.
Probably, the best solution here is for distributions to use their own “user property” for this, and that could apply to operating systems as well. For example, one can imagine “openindiana:sharenfs” as a property. The upshot of that is that these properties might not convey automatically when moving file systems between distributions, but as the semantics (and possibly even syntax) of the contents are assumed not be 100% compatible, probably this is for the very best. It is to be hoped that the NAS vendors building on top of ZFS are already making decent use of user properties (and namespace prefixes) to minimize problems. Certainly that is the case for RackTop. Automatic conversion (or simply using a single shared value) only makes sense when there is broad agreement about the property contents. Absent that, namespace separation, *without* naïve attempts to convert, is probably the next best option. Garrett From: George Wilson Sent: Monday, February 25, 2019 9:43 PM To: openzfs-developer Subject: [developer] Proposal: Platform-specific ZFS properties 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 / see discussions + participants + delivery options Permalink ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/T6b50d98b3cf62715-M8bb55d41c8ed816b1f6128b2 Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
