FYI, for NexentaStor we made sharesmb a "no-inherit" property. (because most customers want "traverse mounts" in SMB, meaning the SMB server exposes descendent file systems)
Note also that the most common situation (by far) for customer configurations is that a shared ZFS dataset should show up in SMB by a predetermined name that the customer pics, not some system made-up thing. I know it looks odd, but the typical sharesmb string for us therefore looks like: sharesmb=name=test (for a share named "TEST") and it gets even more interesting, i.e. sharesmb=name=test,abe=true,PROP=VAL, ... where each "name=something" part starts a new share (yes you can define multiple SMB share names at the same point in your ZFS dataset hierarchy). I find that many are unfamiliar with much of this. Hope this helps. On Wed, Feb 27, 2019 at 3:48 PM <[email protected]> wrote: > > > > 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 / see discussions + participants + delivery > options Permalink ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/T6b50d98b3cf62715-Ma4ceb84e6a98e72986c9d018 Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
