zfs discuss - Aug 2009 - ZFS Crypto Updates [PSARC/2009/443 FastTrack timeout 08/24/2009]

Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
This information is Copyright 2009 Sun Microsystems
1. Introduction
    1.1. Project/Component Working Name:
	 ZFS Crypto Updates
    1.2. Name of Document Author/Supplier:
	 Author:  Darren Moffat
    1.3  Date of This Document:
	17 August, 2009
4. Technical Description

The following changes are being made to the ZFS Crypto design
as documented in PSARC/2007/261

Block Pointer Changes
---------------------

In order to facilitate a future project that allows for an encrypted
(and compressed) "raw" send/recv stream and interaction with the in
progress "BP rewriter (aka device removal work)" the crypto IV
(Initalisation Vector) will now be stored in the BP.

This is done by reusing the third DVA slot.  The impact of this is that
when encryption is enabled on a dataset "copies" can be set to a
maximum
of 2.  Attempting to set copies=3 on an encrypted dataset fails:

   # zfs set copies=3 tank/fs
   cannot set property for ''tank/fs'': copies cannot be set to
3 on encrypted
   datasets.

Since all data blocks in an encrypted dataset are always encrypted with
the same encryption algorithm a single bit is used to store the fact that
this is a pointer to an encrypted block rather than storing the index value
of the encryption property.

On disk wrapped key changes
---------------------------

Instead of a hidden "wrappedkey" property a per objset ZAP object will
be used instead.  This avoids the need to introduce a new binary property
type and also allows for key chains.

A key chain is a set of ZAP objects indexed by txg (transcation group)
the value of the ZAP object is a wrapped key.  This is represented in memory
as an AVL tree of unwrapped keys per dataset.

Simpiler defaults
-----------------
It is no longer necessary to specific the keysource property, if it is
not specififed and encryption is enabled then a default of
"passphrase,prompt"
is assumed.  This allows users to enable encryption easily thus:

  # zfs create -o encryption=on tank/fs
  Enter passphrase for ''tank/fs'':
  Enter again:
  #

AES keylength/modes
-------------------
Based on the performance of AES at various key lengths and the recent
papers in the cryptography community on weakness in AES when used with
a 256 bit key the default "on" value for encryption will be
"aes-128-ccm".
This provides the best performing default and based on current research
in the crypto community it my ironically be stronger than
"aes-256-ccm".
The "aes-192-ccm" mode will also be added.

See: http://eprint.iacr.org/2009/374

This case also seeks approval to add "aes-128-gcm, aes-192-gcm,
aes-256-gcm",
using AES GCM.  From a cryptographic view CCM and GCM are
very similar however GCM is significantly more expensive due to Galois
filed multiplication requirements.  GCM is the preffered mode for 
NSA Suite B compliance so it is included as an option.


Keyscope property removed
-------------------------
The keyscope property and the concept of keyscope is removed.  Instead the
keyscope is always now per dataset and is properly inherited.  With this
all the benefits of the previous keyscope=pool are available while providing
a much simplified admin model that is now consistent with how property
inheritance works in ZFS.  This means there are no crypto related
changes to zpool(1M).

Explain this by example:

  # zfs create -o encryption=on -o keysource=raw,file:///media/my/key tank/fs
 
  At this point a single encrypted dataset exists and is wrapped using the
  AES key in /media/my/key.

  # zfs create tank/fs/sub

  The keysource property is inherited as is the actual value of the wrappingkey.

This is more obvious in the following example:

  # zfs create -o encryption=on tank/a
  Enter passphrase for ''tank/a'':
  Enter again:

  # zfs create tank/a/sub
  
  On creating tank/a/sub the user is NOT prompted to enter a passphrase
  because tank/a is already mounted (ie its key is available) so we inherit
  the wrapping key from our parent.  This also ensures that on import/mount
  the user is only prompted for the passphrase for tank/a and not all the
  child datasets of it.
	
If the user actually wishes to "stop" the inheritance of the
passphrase
(ie the wrapping key value) then they can explicitly set the keysource
property when creating the dataset or performing a key change.


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


Key Change
----------
Due to the above mention keyscope removal the zfs key command now only
accepts a new keyscope property with -o when changing key.   Key change
is also now applied recursilvey in a single transaction to all datasets
inheriting the wrapping key.

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).

Dataset/Clone Rekey
-------------------
A new "-K" flag for ''zfs clone'' is introduced.  If
supplied new data
encryption key will be created in the transaction group the clone is 
created in and used for all data that is unique to the clone.  
The previous state of the keychain will be copied from the origin snapshot.

The ''zfs key'' subcommand also has the "-K" flag, in
this case it will
create a new data encryption key for the named dataset(s).
The rationale for this is allowing compliance with NIST guideless for
the amount of time a data encryption key should be used.

In both the cases the last rekeyed date can be found in the new
''rekeydate''
property.  If a dataset has not been rekeyed then the value of
''rekeydate''
is the same as the ''creation'' date.  For a dataset that is not
encrypted
then the value is "-".

For example:

zfs get -r -H creation,rekeydate tank     
tank    creation        Tue Aug  4 14:37 2009   -
tank    rekeydate       -       default
tank/128g       creation        Tue Aug  4 15:52 2009   -
tank/128g       rekeydate       Tue Aug  4 15:52 2009   local
tank/192g       creation        Tue Aug  4 16:08 2009   -
tank/192g       rekeydate       Tue Aug  4 16:19 2009   local


Summary of zfs(1M) command synopsis
-----------------------------------

zfs key
usage:
        key -l <-a | [-r] filesystem|volume>
        key -u [-f] <-a | [-r] filesystem|volume>
        key -c [ -o <keysource=value>] <-a | [-r] filesystem|volume>
        key -K <-a | [-r] filesystem|volume>


zfs set properties:

 keystatus    NO       NO   undefined | unavailable | available
 rekeyed      NO       NO   <date>
 clonerekey  YES      YES   on | off
 encryption  YES      YES   on | off | aes-128-ccm | aes-192-ccm | aes-256-ccm |
			    aes-128-gcm | aes-192-gcm | aes-256-gcm
 keysource   YES      YES   
keysource=raw|hex|passphrase,prompt|file://<path>


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.

6. Resources and Schedule
    6.4. Steering Committee requested information
   	6.4.1. Consolidation C-team Name:
		ON
    6.5. ARC review type: FastTrack
    6.6. ARC Exposure: open

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

Hi Darren,

Thank you for the update.
Have you got any ETA (build number) for the crypto project?

-- 
Robert Milkowski
http://milek.blogspot.com

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

On Tue, Aug 18, 2009 at 12:37:23AM +0100, Robert Milkowski
wrote:
> Hi Darren,
> 
> Thank you for the update.
> Have you got any ETA (build number) for the crypto project?
Also, is there any word on if this will support the hardware crypto stuff
in the VIA CPUs natively?  That would be nice. :)

-brian
-- 
"Coding in C is like sending a 3 year old to do groceries. You gotta
tell them exactly what you want or you''ll end up with a cupboard full
of
pop tarts and pancake mix." -- IRC User (http://www.bash.org/?841435)

Hi,

Brian Hechinger wrote:
> On Tue, Aug 18, 2009 at 12:37:23AM +0100, Robert Milkowski wrote:
>> Hi Darren,
>>
>> Thank you for the update.
>> Have you got any ETA (build number) for the crypto project?
> 
> Also, is there any word on if this will support the hardware crypto stuff
> in the VIA CPUs natively?  That would be nice. :)
ZFS Crypto uses the Solaris Cryptographics Framework to do the actual
encryption work, so ZFS is agnostic to any hardware crypto acceleration.

The Cryptographic Framework project on OpenSolaris.org is looking for help
in implementing VIA Padlock support for the Solaris Cryptographic Framework:

   http://www.opensolaris.org/os/project/crypto/inprogress/padlock/

Cheers,
   Constantin

-- 
Constantin Gonzalez                              Sun Microsystems GmbH, Germany
Principal Field Technologist                    http://blogs.sun.com/constantin
Tel.: +49 89/4 60 08-25 91       http://google.com/search?q=constantin+gonzalez

Sitz d. Ges.: Sun Microsystems GmbH, Sonnenallee 1, 85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin Haering

Brian Hechinger wrote:
> On Tue, Aug 18, 2009 at 12:37:23AM +0100, Robert Milkowski wrote:
>> Hi Darren,
>>
>> Thank you for the update.
>> Have you got any ETA (build number) for the crypto project?
> 
> Also, is there any word on if this will support the hardware crypto stuff
That has always been the plan and it comes completely for free given it 
uses the Crypto Framework APIs.  I already have acceleration on the 
UltraSPARC T2 processors without have a single special line of code.
> in the VIA CPUs natively?  That would be nice. :)
There isn''t yet a driver/code for the VIA CPUs integrated into the 
crypto framework.  A prototype was started by someone outside of Sun but 
it hasn''t yet integrated:

http://opensolaris.org/os/project/crypto/inprogress/padlock/

The prototype code is here:

http://src.opensolaris.org/source/xref/crypto/padlock/

However that has nothing to do with the ZFS Crypto project directly but 
it will benefit if it is implemented. If you can and wish to help out 
please contact crypto-discuss at opensolaris.org

-- 
Darren J Moffat

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

Garrett D''Amore wrote:
[replying off arc]
> 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.
I''d say I pretty much count as ZFS representation these days as I spend
more of my time in the ZFS code base than anything else.

A lot of the ZFS on disk changes are either ARC''d because there is a 
visible feature or they are really project private implementation details.

The fast system attributes happens to bereally an implementation detail 
that unless you have a very deep understanding of how things work today, 
what Lustre needs and what ZFS Crypto needs it would be pointless to try 
and follow why what it is doing is useful.  The ZFS team might choose to 
bring it to ARC still but I don''t believe there are plans to do so, 
since it is really needed for Lustre first and ZFS Crypto second.

-- 
Darren J Moffat