From owner-freebsd-fs@FreeBSD.ORG Thu Aug 4 13:50:12 2011 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7BDF106564A for ; Thu, 4 Aug 2011 13:50:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C71568FC08 for ; Thu, 4 Aug 2011 13:50:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p74DoCFD071907 for ; Thu, 4 Aug 2011 13:50:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p74DoCTf071905; Thu, 4 Aug 2011 13:50:12 GMT (envelope-from gnats) Date: Thu, 4 Aug 2011 13:50:12 GMT Message-Id: <201108041350.p74DoCTf071905@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Borja Marcos Cc: Subject: Re: kern/157728: [zfs] zfs (v28) incremental receive may leave behind temporary clones X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Borja Marcos List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 13:50:12 -0000 The following reply was made to PR kern/157728; it has been noted by GNATS. From: Borja Marcos To: Martin Matuska Cc: bug-followup@FreeBSD.org, Pawel Jakub Dawidek Subject: Re: kern/157728: [zfs] zfs (v28) incremental receive may leave behind temporary clones Date: Thu, 4 Aug 2011 15:40:03 +0200 On Aug 4, 2011, at 2:33 PM, Martin Matuska wrote: > That is not a solution, we want hidden datasets :) >=20 > A workaround patch is attached that does not prefetch hidden datasets = in > zfs (btw. why should we do that at all). > It doesn't cure the source of the problem but the symptoms - to > reproduce the problem you have to run zfs list or get directly on the > invisible temporary clone now. Well, still there might be a subtle problem. I mean, and sorry if it's a somewhat trivial question, but it-s the = first time I actually read some ZFS internals code ;) Does that prefetch *imply* a temporary lock being placed? I mean, in = such a case usually you need an atomic fetch-and-lock operation. I'm wondering if not prefetching them could be a problem, and = instead it would be a better solution to keep prefetching them but avoiding to display them, so that any side effects are preserved. = Otherwise that might have some ugly interaction. Of course my patch isn't a solution, I wanted a quick experiment to find = out if the special treatment of the hidden datasets was the issue. But, = really, the decision not to show a hidden dataset shouldn't be made at a = such low level because of these interactions. The problem is, the patch = might work but introduce harder to reproduce issues? Maybe Pawel can help us, I guess he's much more familiar than us with = the guts of ZFS ;) Borja.