Darren J Moffat wrote: > I've noticed that the dsl_dataset_t that points to a given dataset > changes during the life time of a 'zfs create' command. We start out > with one dsl_dataset_t* during dmu_objset_create_sync() but by the time > we are later mounting the dataset we have a different in memory > dsl_dataset_t* referring to the same dataset.
Yes, the cached copy can come and go, but the underlying dsl_dataset_phys_t (the dsobj) should be persistent. > > This causes me a big issue with per dataset provided encryption keys, > but not with a per pool provided encryption key. > > When keyscope=dataset we pass the key value used as the wrapping key > down over the ioctl as part of the dataset creation. This makes its way > via dmu_objset_create_sync() to dsl_crypto_key_gen() which generates the > actual encryption key and wraps it using the key that came over the > ioctl, it then stores the wrapped key on disk using zap_update. All > this part works just fine. The last thing that dsl_crypto_key_gen() > does is place the encryption key into ds>ds_key so it can be used later. > When keyscope=pool the only difference with the above is that the > wrapping key is already present in spa->spa_key. > > The problem occurs when the userland zfs_create() attempts to mount the > newly created dataset. The dsl_dataset_t* that was valid during the > creation isn't available anymore and since there is no key we can't > mount the dataset. This sounds similar to what I had to do for the refquota and refreservation properties. You might need to look at pulling in the ds_key zap attribute during dsl_dataset_open_obj(). Take a look at the code for setting ds_reserved and ds_quota. -Chris
