On Tue, 26 Feb 2019 at 13:56, Garrett D'Amore <[email protected]> wrote: > I know that we (RackTop) are moving towards managing file system (dataset) > mounts more manually.
That absolutely makes sense for an appliance where you have extremely specific needs, and total control over the management of ZFS. In the realm of the general purpose illumos distributions, people are likely to continue to use the operating system provided facilities here. > 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. I'm not really sure that's true. The general purpose illumos distributions that exist today all interpret these properties in the same way: by passing the values to the operating system level share management routines. This is even true on SmartOS, where we've perhaps diverged the most in terms of how we expect the operating system to be managed. > 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? As Matt described in the call today, ZFS system-level properties are for providing behaviours where ZFS needs to be involved. For instance, if you use "zfs rename" on an exported dataset, it may unshare before renaming, and reshare after renaming. If you create child datasets where these properties are inherited, you need to take action there too. There is necessarily code in ZFS itself to arrange for those behaviours at the appropriate point in the dataset lifecycle. Though the properties are system-level because of the lifecycle aspect, their contents is nonetheless interpreted in an operating system-specific fashion. That's at the heart of what this proposal sets out to address. > 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. That's a good question. I think it's probably possible to make the right determination somehow. If it isn't, it would also be possible for ZFS to say "I don't support that system-level property on this system" while not affecting the ability of other more integrated platforms to continue to provide it. > 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. I don't think anybody is suggesting automated transformation of the contents of the values. To the extent that George spoke of conversion in the original mail, I believe it was about moving a pool from before a change like this to after a change like this; do you or do you not copy the value from the then-legacy "sharenfs" to "sharenfs_SunOS" or "sharenfs@illumos", etc, rather than if and how you might transform the contents. > This feels like a solution in search of a problem. That's not true. As we've discussed twice on the the OpenZFS call, and as George outlined in his mail, there are folks who have real reasons to have pools that are either transitioning from one platform to another, or which need to be importable on more than one platform over their lifetime. Today, using the system-level properties that have OS-specific interpretations is not safe; this proposal seeks first to make that safe by not doing the wrong thing, then to make it useful by enabling the right thing to happen in an explicit fashion. Cheers. -- Joshua M. Clulow Engineer @ Joyent http://blog.sysmgr.org ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/T6b50d98b3cf62715-M721f84148bcb9259abae13fe Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
