Darren J Moffat wrote: > 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.
Ah, OK, I didn't catch the distinction between the keys. So is it possible for a snapshot to have a different unwrapping key than the head dataset? I would think not, since the blocks in a snapshot were created as part of the head ds. I'm wondering whether the dsl_dir_t is the more logical place to keep the unwrapping key. Although that doesn't solve this issue, since the dsl_dir_t structs come and go from memory too.
