Chris Kirby wrote: > 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.
But the unwrapped key isn't in the dsl_dataset_phys_t - by design otherwise the whole crypto is pointless since the key is on disk. The wrapped key is in the zap and if keyscope=pool the I can unwrap it because the unwrapping key is in the spa. If keyscope=dataset my unwrapping key is ?????? - this is the problem case. > 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. I see the use of dsl_prop_get_ds_locked() for those properties during a dsl_dataset_open_obj(). What I'm looking for is something that is always (during the whole create until it is umounted) present in memory where I can place the unwrapped key. Maybe that doesn't exist and I need to rethink the way per dataset keying is done. -- Darren J Moffat
