On 11/16/12, "Edward Ned Harvey (opensolarisisdeadlongliveopensolaris)" wrote: > > From: zfs-discuss-boun...@opensolaris.org > > [mailto:zfs-discuss-(javascript:main.compose() > > boun...@opensolaris.org] On Behalf Of Jim Klimov > > > > Well, as a simple stone-age solution (to simplify your SMF approach), > > you can define custom attributes on dataset, zvols included. I think > > a custom attr must include a colon ":" in the name, and values can be > > multiline if needed. Simple example follows: > > > > # zfs set owner:user=jim pool/rsvd > > > > Then you can query the zvols for such attribute values and use them > > in chmod, chown, ACL settings, etc. from your script. This way the > > main goal is reached: the ownership config data stays within the pool. > > Given that zfs doesn't already have built-in support for these properties at > mount time, given the necessity to poll for these values using an > as-yet-unwritten SMF service, I'm not necessarily in agreement that zfs > properties is a better solution than using a conf file to list these > properties on a per-vdev basis. Either way, a SMF service manages it, and > it's difficult or impossible to trigger an SMF to occur on every mount, and > only on every mount. So the SMF would have to be either a one-time shot at > bootup or manual refresh (and consequently miss anything mounted later) or it > will have to continuously poll all the filesystems and volumes in the system.
The case that occurred to me is when you move a zpool from one server to another. You don't have to worry about moving the configuration file and keeping it updated, just in keeping your SMF services in sync between servers, and your configuration properties are part of the pool you already imported, and are automatically consistent with what they were before on the last server. > > An easier event to trigger is the starting of the virtualbox guest. Upon vbox > guest starting, check the service properties for that instance of vboxsvc, > and chmod if necessary. But vboxsvc runs as non-root user... > > I like the idea of using zfs properties, if someday the functionality is > going to be built into ZFS, and we can simply scrap the SMF chown service. > But these days, ZFS isn't seeing a lot of public development. > > If we assume the SMF service is the thing that will actually be used, from > now until someday when BTRFS eventually eclipses ZFS, then I would rather see > a conf file or SMF service property, so the SMF service doesn't constantly > scan all the filesystems and volumes for their zfs properties. It just checks > the conf file and knows instantly which ones need to be chown'd. > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss -- -- ----------------------------------------------------------------------------------- Brian Wilson, Solaris SE, UW-Madison DoIT Room 3114 CS&S 608-263-8047 brian.wilson(a)doit.wisc.edu 'I try to save a life a day. Usually it's my own.' - John Crichton ----------------------------------------------------------------------------------- _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
