I know that we (RackTop) are moving towards managing file system (dataset) mounts more manually.
I’m not specifically aware of ways that illumos systems have a different parsing or semantic of sharenfs or sharesmb in particular, but I can see that this is likely to be the case in the future for the SMB side as well. My take on it is that if people are applying system specific properties here, then they probably should not be using “generic” properties for that. The concern is that the ways in which the syntax, or semantics, of these properties may be sufficiently different that it would be a mistake to try to apply some kind of mapping to a common semantic. Of course if the semantics and syntax are *not* that different, then why do we need OS-specific properties at all? Also, for distributions, how will the “system” understand what distribution specific property to use? For example, if the NFS server implementation is shipped separately from ZFS (which is likely commonly the case for Linux), there may not be any obvious way for the ZFS code to determine whether the distribution is RedHat, Ubuntu, KUbuntu, or any one of dozens of variants. And yet the details here may matter. In the case of sharenfs, probably the semantics of the property are well understood and reasonably portable. Distributions that can consume the generic property should do so. If they can’t, or they need special extra data, then probably they should invent a distribution specific property (or several), which may be used to supplement the standard one. The details are – left up to the distribution. 😊 I dislike any kind of automated conversion of these properties. I would far rather leave things alone now, and let distros either cope with the common syntax, or invent their own properties as needed. This feels like a solution in search of a problem. Garrett From: Matthew Ahrens Sent: Tuesday, February 26, 2019 1:27 PM To: openzfs-developer Subject: Re: [developer] Proposal: Platform-specific ZFS properties 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 / openzfs-developer / see discussions + participants + delivery options Permalink ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/T6b50d98b3cf62715-Mc06a1825e5c104312acae772 Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
