> On Feb 25, 2019, at 9:53 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.
Yes. Also consider that there are multiple implementations of the shares. For example, shareiscsi on Linux could refer to no less than 4 completely different iscsi target implementations. > > 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. Oracle's change from sharesmb to share.smb seems to try to address some sort of namespace unification. But it still relies on the backend being unified (share(1m)) -- very unlikely to happen elsewhere. IMHO Oracle's naming change is not sufficiently different from user properties to warrant a whole new dot-separated naming scheme. > > 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. Or redesign entirely. The ease of sharing at filesystem mount time is trivial to recreate using sysevents. What is difficult to do with sysevents is unsharing prior to umount. A generic plugin might be easier and more extensible for those services that are beyond NFS/SMB (eg BeeGFS) 1. run this after mount 2. run that prior to umount -- richard ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/T6b50d98b3cf62715-M73dbfd564ac4bec338afe810 Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
