Garrett D'Amore wrote:
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.
The above is the draft man page text. What more would you like to see ?
Is it that you don't understand the behaviour or you want to do an
editoral review of the man page text ? If the later then I'd assert
that isn't ARC review.
As an alternative to failure, could one imagine having a "-f" (force)
switch that allows the rename, and creates a new keysource root?
We can't do that because you need to specify what the keysource is. So
a force switch would be more like:
# zfs rename -o keysource=... tank/A/b/c tank/D/e/c
However 'zfs rename' doesn't have a -o capability today and it is out of
the scope of the crypto project to add that support to rename. It is
possible to add in the future but it has a non trivial impact beyond
crypto support so I'm not willing to take that on just now -
particularly since it requires changes to libzfs APIs that are in use by
Fishworks.
I've logged an RFE for the general case: 6872829
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?
Yes, and this is unchanged from the previous PSARC case for ZFS Crypto.
> Is there any indication to the administrator that this is
the situation?
Unchanged from the previous PSARC case for ZFS Crypto.
The aren't mounted and shown in df, the mounted property of the dataset
is false and the keystatus property is unavailable.
> 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.
This is unchanged from the previous case.
There is a private implementation detail where we ensure that the SMF
service that runs at boot does not attempt to prompt. This is because
SMF doesn't provide any means to do so, and even if it did we may not
want that to happen.
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.
This is not an ARC issue in any many other ZFS cases and I'm not making
it one in this case either, because it isn't this project that is
introducing fast system attributes. Not all ZFS changes that impact on
disk actually come to ARC anyway.
Is the fast system attributes project planning on changing the on-disk
format?
Yes but in a compatible way using the version system, there is nothing
directly visible to admins.
To enable encryption you have to upgrade your pool version number anyway
- this is standard ZFS behaviour when adding new features that have an
on disk impact. That was already the case with the previous ZFS Crypto
ARC case. Encryption support will be a pool version after the fast
system attributes project and encryption depends on it. However I don't
expect to see an ARC case presented to PSARC for the fast system
attributes project since there is nothing visible to the admin other
than the pool version bump. The main reason for integration fast
system attributes separately from crypto is because there is another non
ON (and not in Sun ARC control) consumer for them (and no it isn't
Fishworks).
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.
The core senior members of the ZFS team contributed to this design and
have provided input during an extensive review period.
A representative of Fishworks was also present during the design of
these changes (back in Feburary) and indicated they were happy with the
changes.
(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.)
Which is why this has had very extensive review from senior members of
the core ZFS team.
--
Darren J Moffat
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
