Certainly going with user-defined properties would solve the problem of safety but it comes at the cost of the administrative model. The administrators would now be required to know the correct vendor/distribution combination for each platform in order to change a given property. Any existing scripts would now break with this model too. It also introduces namespaces to avoid property name collisions. Distributions would have to define their namespaces which could then be changed by vendors that consume and modify them. This isn't a new problem, but would be a new problem for what were once native properties that are now moved to user-defined properties. I don't have a sense for what the impact would be if we go down this path since I'm not sure how many people rely on such properties as "sharenfs" and "sharesmb". I suspect that illumos uses them the most, followed by freebsd, and then linux, but that's just a guess.
The goal of the proposal was not to put that burden on the admins but rather try to preserve the native properties while still providing cross platform safety. It also seems to me that if vendors and distributions are already going down the path of creating incompatibilities in their implementations, then they don't care about or haven't thought about cross platform safety. And if we can provide automatic conversion of a native property to a platform-specific property then we haven't made it worse for them. I guess the question we should first answer is whether or not we want to keep these native properties as native properties. Should they stay or should they go? Effectively moving them from native properties mean deprecating them and allowing distributions/vendor to move down the user-defined path if they so wish. On Mon, Feb 25, 2019 at 10:54 PM Garrett D'Amore <garr...@damore.org> wrote: > 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 <george.wil...@delphix.com> > *Sent: *Monday, February 25, 2019 9:43 PM > *To: *openzfs-developer <developer@lists.open-zfs.org> > *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 <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 <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-M8bb55d41c8ed816b1f6128b2> > ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/T6b50d98b3cf62715-M8e54d5781236f9bd962c8f6c Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
