On Fri, Jan 11, 2008 at 06:05:48PM +0000, Darren J Moffat wrote: > >>>Can an encrypted dataset (keytype=dataset) reside in a non-encrypted (no > >>>kek defined) pool? > > > >In terms of usability, I think that'd be real nice -- no need to rebuild > >existing pools! > > You wouldn't need to rebuild just have the pool admin run:
Oh good. > >So why wouldn't the admin want to allow users to encrypt their data? > >Because of resource consumption? But user processes be charged for > >whatever cycles they use for ZFS crypto? (I guess additional memory use > >is another story.) > > That is one reason, another might be site policy (for what ever reason) > or because they are using crypto below ZFS using some other "hardware". *shrug* Resource usage is the only really good reason for restricting ZFS crypto usage that I can come up with. > >(b) means that zfs create -o encryption=on could be interactive. I > >think that's OK, but see below. > > I was explicitly trying to avoid making any existing command go interactive. As long as it only happens with new options I don't see why not. What sort of principle applies that couldn't be excepted? > >Alternatively, let zfs create -o encryption=on create "larval" datasets > >that aren't actually created until keyed, but which do persist on disk > >until destroyed, and can be listed, even renamed, but not snapshotted > >nor mounted. > > I'm looking at that just now but it isn't as trivial as it might appear. Oh, I imagine it isn't. It might be, but probably isn't.
