Matthew Ahrens wrote:
>> You can set the property attribute to be readonly and invisible which
>> would keep anybody from touching via the zfs(1) command.
>
> Right, but Darren wants it to exist in userland at all (eg, for no ioctl
> to mention its existence). I believe that readonly/invisible
George Wilson wrote:
> Darren J Moffat wrote:
>> Is it possible to have dataset properties that are managed using the
>> dsl_prop_set() / dsl_prop_get() interfaces that aren't made available
>> via zfs(1), in fact I probably don't want them in userland at all.
>>
> You can set the pd_visible f
Is it possible to have dataset properties that are managed using the
dsl_prop_set() / dsl_prop_get() interfaces that aren't made available
via zfs(1), in fact I probably don't want them in userland at all.
Specifically I'm wondering if I can use dsl_prop_set() to store the
wrapped encryption ke
gt;
>>>
>>>
>>>
>> You can set the property attribute to be readonly and invisible which
>> would keep anybody from touching via the zfs(1) command.
>>
>
> Fantastic.
>
> If I do that can I inside the zfs kernel module make it readwri
Matthew Ahrens wrote:
> George Wilson wrote:
>> Darren J Moffat wrote:
>>> Is it possible to have dataset properties that are managed using the
>>> dsl_prop_set() / dsl_prop_get() interfaces that aren't made
>>> available via zfs(1), in fact I probably don't want them in userland
>>> at all.
>>>
Darren J Moffat wrote:
> Is it possible to have dataset properties that are managed using the
> dsl_prop_set() / dsl_prop_get() interfaces that aren't made available
> via zfs(1), in fact I probably don't want them in userland at all.
>
You can set the pd_visible field in the zfs_prop_table[]
George Wilson wrote:
> Darren J Moffat wrote:
>> Is it possible to have dataset properties that are managed using the
>> dsl_prop_set() / dsl_prop_get() interfaces that aren't made available
>> via zfs(1), in fact I probably don't want them in userland at all.
>>
> You can set the pd_visible f
