Am 26.02.2019 um 06:42 schrieb George Wilson: > > 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. > The general problems I have with the share* mechanics: - It's baked into ZFS, to change how the properties are interpreted I have to either code in C and recompile ZFS or neuter the call to 'zfs (un)share' to make it do what I need - They inherit, while this is often needed to share filesystem hirarchies over NFS it's mostly counterproductive for SMB (as that can handle sub-filesystems) - They're one-property containing all options (to the respective daemon), this gives problems when doing complex shares, not all features of respective daemons are not supported, inheritance boild down to take it as it is or copy&paste from the parent and edit.
What I would like to see is to move the (un)share functionaly to external executeables (so #! scripts work for the ones not fluent in C) that give a clear interface for share/unshare/reload <dataset> so they are easily replaceable in case the on-size-fits-all the ZFS brings out of the box dosn't work for someone for whatever reason. IMHO best would be to have shareX (X being SMB, NFS, whatever) simply being on|off and a schema for sub-properties (along shareX:property=value, or a sane format) that is monitored by ZFS so should one of these be modified on a currently shared dataset the respective external helper could be called with 'reload <dataset>' to adjust to the new setting (as some daemons can modify their behaviour on the fly so unshare/share cycle can be avoided as it would lead to service interruption) and construct a configuration the respective can digest. Then these sub-properties could be made platform specific as suggested by George. That's my 2 cents from a user perspective. Gregor ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/T6b50d98b3cf62715-Me3419057543c1be0ae0a3a5b Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
