Darren J Moffat wrote:
>
> Dataset rename restrictions
> ---------------------------
>
> On rename a dataset can non be moved out of its wrapping key hierarchy
> ie where it inherits the keysource property from. This is best explained
> by example:
>
> # zfs get -r keysource tank
> NAME PROPERTY VALUE SOURCE
> tank keysource none default
> tank/A keysource passphrase,prompt local
> tank/A/b keysource passphrase,prompt inherited from tank/A
> tank/A/b/c keysource passphrase,prompt inherited from tank/A
> tank/D keysource none default
> tank/D/e keysource passphrase,prompt local
>
> Simple rename of leaf dataset in place:
> # zfs rename tank/D/e tank/D/E OK
>
> Rename within keysource inheritance remains the same:
>
> # zfs rename tank/A/b/c tank/A/c OK
>
> Rename out of keysource inheritance path:
>
> # zfs rename tank/A/b/c tank/D/e/c FAIL
>
I'd like to see draft text for a man page describing this behavior. I
suspect that this is likely to be potentially confusing.
As an alternative to failure, could one imagine having a "-f" (force)
switch that allows the rename, and creates a new keysource root?
> Dataset mount
> -------------
> The zfs_mount() library call in libzfs, and thus zfs(1M) mount command
> will load keys if they are available when a dataset is attempting to be
> mounted. Note that this means that 'zfs mount -a' can attempt to be
> interactive if the keysource locator is "prompt". Note that this does
> NOT cause a prompt for system boot and we do NOT wait looking for keys
> (there is no facility to do so with SMF anyway).
>
So what is the behavior at boot for these file systems? Are they left
unmounted? Is there any indication to the administrator that this is
the situation? The man page indicates that zfs mount -a is run at boot,
but it seems like this might be a special case. Again, this is one I'd
like to see supporting man page diffs for.
>
> Dnode Bonusbuf Encryption
> -------------------------
> Instead of encrypting the bonusbuf section of the dnodes the ZFS Crypto
> feature
> will now depend on the ZFS fast system attributes project and will cause
> the bonusbuf to always completely spill. Note there are no user visible
> interface change from this and the ZFS fast system attribtues project isn't
> expected to be reviewed in ARC as it is an implementation detail only.
> Management of the dependency is thus not an ARC issue but an internal team
> coordination issue.
>
Implementation details that affect on disk storage, or have other larger
ramifications elsewhere on the system, should probably still be ARC'd.
Is the fast system attributes project planning on changing the on-disk
format?
The rest of the changes proposed look good as is to me, but I'd also
like an explicit statement from the ZFS (and perhaps a;lso Fishworks)
core team that they have reviewed and approved this proposal. Since I
suspect you're working rather closely with them on this project, that
shouldn't be too hard to achieve.
(My concern here is that I think it is likely that nobody else on ARC
has sufficient filesystem -- or perhaps just ZFS -- expertise to perform
a meaningful review on our own. This is a situation which I would
*like* to see rectified by having storage represented at ARC, but I've
as yet been unable to generate sufficient interest from the storage folks.)
Thanks.
- Garrett
