Date: Thu, 4 Aug 2011 14:20:12 GMT From: Martin Matuska <mm@FreeBSD.org> To: freebsd-fs@FreeBSD.org Subject: Re: kern/157728: [zfs] zfs (v28) incremental receive may leave behind temporary clones Message-ID: <201108041420.p74EKCbY098803@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/157728; it has been noted by GNATS. From: Martin Matuska <mm@FreeBSD.org> To: Borja Marcos <borjam@sarenet.es> Cc: bug-followup@FreeBSD.org, Pawel Jakub Dawidek <pjd@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201108041420.p74EKCbY098803>