Hi Ethan,
the fix is fine taking into account the fact that TI supports for now
only subset
of features planned for Spring and that the installer is the only ZFS TI
consumer
as time of being.
I have some more generic questions in order to clarify how these changes
would
fit into next version of TI, which will support also other consumers
(Snap Upgrade, Distribution Constructor).
Please see below.
Thank you,
Jan
[1] I can see that you have introduced some new attributes describing
ZFS target:
TI_ATTR_ZFS_INIT_BE_NAME
- I suppose this is name of BE to be created ? Since there is _INIT_
part in attribute name, is there some intent to have also other BE
types ? If so, how they would differ ?
TI_ATTR_ZFS_SHARED_FS_[NUM|NAMES]
- Originally, TI ZFS module didn't distinguish between shared and
non-shared filesystems. Looking the the code, it seems to me that
from TI point of view, there are two differences:
* non-shared filesystem is created on <root_pool>/ROOT/<be_name>/<fs_name>,
shared filesystem omits ROOT/<be_name> part.
* since shared as well as non-shared filesystems needs to be mounted
on <alt_root>/<fs_name> mount point, different "zfs mount" command
needs to be used.
Could you please let me know, if it this observation is correct ?
[2] Modification to TI ZFS module.
zfm_create_fs() function taking care of creating ZFS target now requires that
* TI_ATTR_ZFS_INIT_BE_NAME is provided and based on this attribute, special
kind of actions is applied to ZFS target during "create" and "mount"
operations.
* both TI_ATTR_ZFS_SHARED_* and TI_ATTR_ZFS_FS_* has to be provided.
Due to above restrictions, zfm_create_fs() is now specific to how
BE is designed and can't take care of creating other type of ZFS dataset.
Would you like to have this BE logic to be implemented in TI for Snap Upgrade
project ?
I am fine with this approach - just I would need to be aware of this,
since Distribution Constructor will also use TI for creating ZFS data
sets, so I would then need to encapsulate BE part and refactor the code
a bit, so that it doesn't collide with what TI is assumed to support
from ZFS part of view.
[3]One thing which might be helpful for next design was not implemented in
October release, but will be supported in Spring one - as far as ZFS data
sets are concerned TI will be able to set ZFS dataset properties
according
to attributes provided. There will be following TI attributes introduced:
TI_ATTR_ZFS_FS_PROPERTIES - nvlist array
- will contain nvlist for every dataset to be created
Every nvlist then will provide:
TI_ATTR_ZFS_FS_PROP_NAMES, TI_ATTR_ZFS_FS_VALUES - both are string arrays
array of name-value pair ZFS dataset properties
Thanks to this, it will be possible to set any ZFS dataset property to
any value (compression, quota, mountpoint, ...).
Ethan Quach wrote:
> Can someone do a review of this bugfix. Its targeted for the preview2
> release, so a review in the next couple working days would be appreciated.
>
> 354 better hierarchy for initial datasets
>
> Bug:
> -----
> http://defect.opensolaris.org/bz/show_bug.cgi?id=354
>
> webrev:
> ----------
> http://cr.opensolaris.org/~equach/webrev.354/
>
>
> Thanks,
> -ethan
> --
> This message posted from opensolaris.org
> _______________________________________________
> caiman-discuss mailing list
> caiman-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
