On Sat, Sep 05, 2009 at 02:56:21PM +0200, Ricardo M. Correia wrote: > Hi Pawel, > > Unfortunately your fix will not work correctly, because the DMU code > expects all of the dnode_t fields to be initialized to 0 after > allocation, which will not happen if you eliminate that call.
And this is not what constructor is doing? Could you explain what doesn't work here exactly? From my understanding (at least that's the case for FreeBSD's zone allocator) kmem_cache will call constructor after allocating the memory. If it isn't called after allocation then when? > In fact we had the same "fix" in the Lustre tree for a while, but it led > to assertion failures during testing due to that problem. > > I am attaching a patch that contains a more thorough fix, however please > note that this hasn't gone through a complete code review, not from the > Lustre team nor from the ZFS team. It seems to be working reasonably for > us in our very limited testing, but use at your own risk :-) > > I am planning to do a code review of this patch and integrate it into > Nevada some time in the future, along with some other minor bug fixes. -- Pawel Jakub Dawidek http://www.wheel.pl pjd at FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-code/attachments/20090905/923e24f7/attachment.bin>