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

[Martin Matuska]

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

From: Martin Matuska <mm at FreeBSD.org>
To: Borja Marcos <borjam at sarenet.es>
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, 04 Aug 2011 16:18:48 +0200

 What is for sure that there is an additional lock placed on the clone
 that is not removed, or at least not immediately.
 The fact that you are able to delete the clone afterwards means that the
 lock has been released - it might be a race between tasks.
 In my opinion the lock is placed on any access on the temporary clone
 (no mater if prefetch or fetch).
 But I still think we don't have to prefetch data we are not processing.
 
 I don't think that there will be any ugly interaction in this case.
 The idea of the prefetch code is to speed up access to the data
 structure by caching it into memory.
 So what we don't prefetch (is not cached) will be read the normal way
 (and not from cache).
 
 If you follow its history, you can see it well:
 
 Prefetch for zfs list was introduced in OpenSolaris changeset 8415 and
 didn't change very much since that point:
 http://hg.openindiana.org/illumos-gate/rev/d5525cd1cbc2
 
 If you remove that code, it will still work the way it should, but slower :)
 I still see no problem in not-prefetching hidden datasets.
 
 Dňa 04.08.2011 15:40, Borja Marcos wrote / napísal(a):
 > On Aug 4, 2011, at 2:33 PM, Martin Matuska wrote:
 >
 >
 > 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 ;)
 -- 
 Martin Matuska
 FreeBSD committer
 http://blog.vx.sk