kern/157728: [zfs] zfs (v28) incremental receive may leave behind temporary clones

[Borja Marcos]

The following reply was made to PR kern/157728; it has been noted by GNATS.

From: Borja Marcos <borjam at sarenet.es>
To: Martin Matuska <mm at FreeBSD.org>
Cc: bug-followup at FreeBSD.org,
 Pawel Jakub Dawidek <pjd at FreeBSD.org>
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.