On Wed, Dec 03, 2014 at 08:47:21PM -0500, Josef 'Jeff' Sipek via illumos-zfs
wrote:
> On Wed, Dec 03, 2014 at 05:41:31PM -0800, Matthew Ahrens wrote:
> > On Wed, Dec 3, 2014 at 5:37 PM, Josef 'Jeff' Sipek via illumos-zfs <
> > z...@lists.illumos.org> wrote:
> >
> > > So, the reason I managed to f
On Wed, Dec 03, 2014 at 05:41:31PM -0800, Matthew Ahrens wrote:
> On Wed, Dec 3, 2014 at 5:37 PM, Josef 'Jeff' Sipek via illumos-zfs <
> z...@lists.illumos.org> wrote:
>
> > So, the reason I managed to find this is because I tried to remove the
> > global dbuf hash table - making use of the per-dn
On Wed, Dec 3, 2014 at 5:37 PM, Josef 'Jeff' Sipek via illumos-zfs <
z...@lists.illumos.org> wrote:
> So, the reason I managed to find this is because I tried to remove the
> global dbuf hash table - making use of the per-dnode dbuf avl trees to find
> dbufs.
>
>
I imagine that the performance imp
On Wed, Dec 03, 2014 at 05:10:11PM -0800, Alex Reece wrote:
> I think you're totally right, that is a bug - we change the dbuf in the avl
> tree in a way that changes its order in the avl tree without updating the
> tree.
>
> I don't particularly know why this hasn't blown up before, but I suspect
I think you're totally right, that is a bug - we change the dbuf in the avl
tree in a way that changes its order in the avl tree without updating the
tree.
I don't particularly know why this hasn't blown up before, but I suspect
its because whenever we do an avl_find() in this tree, we are looking
