Date: Thu, 4 Aug 2011 15:40:10 GMT From: Borja Marcos <borjam@sarenet.es> To: freebsd-fs@FreeBSD.org Subject: Re: kern/157728: [zfs] zfs (v28) incremental receive may leave behind temporary clones Message-ID: <201108041540.p74FeALk072229@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: Borja Marcos <borjam@sarenet.es> To: Martin Matuska <mm@FreeBSD.org> 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, 4 Aug 2011 17:37:26 +0200 On Aug 4, 2011, at 4:18 PM, Martin Matuska wrote: > But I still think we don't have to prefetch data we are not = processing. >=20 > 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). >=20 > If you follow its history, you can see it well: >=20 > 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 >=20 > 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. Understood :) Thank you very much. As I said, I'm not that familiar with = the internals. I'm going to try the patch and will let you know the outcome. I guess = it will effectively fix it. Best regards, Borja.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201108041540.p74FeALk072229>