Re: [OpenZFS Developer] [openzfs] 6458 kmem reap thread gets blocked in reclaim callback (#38)

2015-11-17 Thread Matthew Ahrens
> @@ -1508,7 +1509,15 @@ exi_cache_trim(struct exportinfo *exi) >* used for NFSAUTH_CACHE_TRIM seconds. >*/ > for (c = avl_first(tree); c != NULL; c = AVL_NEXT(tree, c)) { > - rw_enter(>authc_lock, RW_WRITER); > +

Re: [OpenZFS Developer] zfs send not detecting new holes

2015-11-17 Thread Boris
Hi, Matt, I believe I did reproduce the problem. The difficulty was really with creating an L1 hole. Which I managed with a zfs recv of an empty L1 range from one zvol to another. The target zvol had L1 hole in place of the L1 range filled with L0 holes in the source zvol. The issue that I

Re: [OpenZFS Developer] [openzfs] 6458 kmem reap thread gets blocked in reclaim callback (#38)

2015-11-17 Thread George Wilson
> @@ -1508,7 +1509,15 @@ exi_cache_trim(struct exportinfo *exi) >* used for NFSAUTH_CACHE_TRIM seconds. >*/ > for (c = avl_first(tree); c != NULL; c = AVL_NEXT(tree, c)) { > - rw_enter(>authc_lock, RW_WRITER); > +

Re: [OpenZFS Developer] zfs send not detecting new holes

2015-11-17 Thread Boris
So, I am thinking to try modifying dbuf_read_impl() to fill the arc buf with appropriate level holes instead of doing bzero() when reading metadata-level holes whose birth epoch is greater than zero (or greater than the than the hole_birth feature txg perhaps). Boris.