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>

Reply via email to