Darren J Moffat wrote:
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.
Neither. I want to make sure we present this behavior in an unconfusing
to our users. If the above is intended to be in the man page, then I'm
satisfied.
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
Okay, I'm satisfied with your answer to this.
[ other bits I'm satisfied with elided. ]
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).
Hmm.... that's too bad. I think it would still be preferable for
changes of this nature to get at least some minimal review at ARC.
Although as we don't have any ZFS representation at ARC, maybe review of
such changes wouldn't add anything useful.
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.
Okay, I was pretty sure this was the case, just wanted to make sure it
was explicitly stated as true. :-)
With your replies, +1 to the case. Thanks for your patience.
- Garrett
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
