> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- > 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. 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
