Dave Miner wrote:
> William Schumann wrote:
>> Since the OpenSolaris Automated Installer is being enhanced to create
>> zfs pools, setting properties of zfs filesystems and pools should
>> also be considered.
>>
>> A zfs root pool is created automatically when OpenSolaris is
>> installed, and the design proposal includes creating other zfs pools
>> and extending them to multiple disks.
>>
>> This message suggests possibilities for new features for the the
>> OpenSolaris Automated Installer. Community input is requested.
>>
>
> I'm not clear on what you're proposing, exactly, but it appears that
> you're suggesting something other than just passing through a list of
> ZFS properties. The concern I would have about any other approach is
> that the ZFS property list is extensible, including user properties,
> and so I'm skeptical there's value added by AI knowing anything about
> the specifics of the properties.
Are you proposing just passing through a text string that specifies options:
zfs create -o <option string>
where option string is a list of zfs options as you would type on a
command line? This seems fraught with risk as it would be difficult to
validate, and the smallest syntax error or inappropriate usage would
break the install.
What I am proposing is that we support certain options by providing AI
manifest elements and having the user fill in the values. e.g., the
mountpoint and compression properties:
<ai_zfs_pool>
<action>create</action>
<name>newpool</name>
<mountpoint>/export</mountpoint>
<compression>on</compression>
...
</ai_zfs_pool>
Doing it this way would allow us to validate the mountpoint as a path.
Other semantic validation is possible with this approach.
On the other hand, the option string could be parsed and validated as
the 'zfs' command does. Also, the schema and code would not have to
keep pace with new features.
Another approach would be to have schema elements for the more popular
options and allow an additional option string so people could select
options AI does not explicitly provide:
<ai_zfs_pool>
<mountpoint>/export</mountpoint>
<option_string>quota=30g</option_string>
...
</ai_zfs_pool>
William
>
> Dave
>
>> zfs filesystem specification - suggest:
>>
>> compression - turn on and select the compression algorithm
>> mountpoint - where the zfs filesystem will be mounted on the new system
>> quota - set file system quota
>>
>> A zfs upgrade could also be specified, so that a new OpenSolaris is
>> installed and an old zfs filesystem could be upgraded at the same
>> time. The same logic might apply to snapshots - upgrade OpenSolaris
>> and take snapshots of existing file systems.
>>
>> zfs file systems could be configured for sharing via nfs or smb.
>>
>> zfs file system properties casesensitivity, normalization, and
>> utf8only cannot be changed once the file system is created, and
>> should perhaps be provided for this reason alone.
>>
>> User and group access permissions can be set.
>>
>> zpool property: failmode - control behavior if failure
>>
>> zpools can be upgraded and snapshots taken as well.
>>
>> vdevs can be added to or removed from existing zpools.
>>
>> There are many other possible zfs-related features to be offered.
>> Suggest starting by supporting a basic set of the most useful ones,
>> as they can become complex to implementand validate, and can
>> complicate installation, possibly leading to failure due to small
>> technicality in less important options.
>> _______________________________________________
>> caiman-discuss mailing list
>> caiman-discuss at opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>
