The unmount prior to sharing is actually interesting… while it isn’t particularly cross-platform, its very analogous to the problems we had with dynamic reconfiguration, where we wanted to vacate I/O from an adapter prior to removal. We generalized this into the notion of vacation a “resource”, and there is a software subsystem called “RCM” (reconfiguration coordination manager or somesuch) that supports this. We could (for illumos) extend that framework.
Ultimately I really do believe that its difficult to come up with a cross-platform solution here; and I’m not super thrilled with trying to invent one. For example, the very notion of being able to fork a program to run at unmount time may be challenging in some environments. For example, on Windows (yes there is a Windows ZFS port), this might mean different things. Even under POSIX systems, under what UID should the program be run? Could this conceivably be used to create a privilege escalation vector? Etc. How do you handle failures that occur if the program runs? The whole thing, which at first blush seems simple, quickly turns into a morass I think. I think the best solution is to punt. Those of us that are NAS vendors already know how to manage this cleanly anyway. Garrett From: Richard Elling Sent: Tuesday, February 26, 2019 10:34 AM To: openzfs-developer Subject: Re: [developer] Proposal: Platform-specific ZFS properties On Feb 25, 2019, at 9:53 PM, Garrett D'Amore <[email protected]> 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 / see discussions + participants + delivery options Permalink ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/T6b50d98b3cf62715-Mbf5be774f90e5db157657a25 Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
