Darren J Moffat wrote: > johansen wrote: >> Hi Darren, >> I took a look at your webrev and have a couple of questions: >> >> 1. When you built this source did you clobber all of the kernel >> portion and rebuild? > > I've done a full clobber build and it still happens. > >> I ask this because in your sdiff for uts/common/fs/zfs/sys/dnode.h >> you've inserted the dnode structure member dn_crypt above dn_nlevels. >> If you have code that is trying to manipulate dn_crypt but some old >> code still references dn_nlevels at the offset of dn_crypt, you're >> going to run into very strange problems. >> >> 2. If you've performed a clobber build, this could potentially >> indicate a corrupted dnode_phys_t or corrupted objset_impl_t. The >> dnode gets dn_nlevels set from dmu_objset_create_impl where it pulls >> the value our of the objset os_meta_dnode. In dnode_create, it uses >> the dnode_phys_t's dn_nlevels to set the value. If the value is >> getting set to zero by one of these routines you may have corrupted >> something in the objset or the dnode_phys. Have you investigated what >> is going on with these structures? > > Thats what I though to but I've looked at all the places where a dnode_t > is translated into something else and none of them appear to be wrong. > > If I operate on an existing Version 3 pool I don't have any of these > problems. This only happens when using a Version 4 (crypto is version 4 > in my workspace) pool. > > Thanks for your suggestions, but I'm still stuck! >
Not sure if you've already posted this or not, but do you have a webrev? eric
