On Thu, May 26, 2011 at 09:04:04AM -0700, Brandon High wrote: > On Thu, May 26, 2011 at 8:37 AM, Edward Ned Harvey > <opensolarisisdeadlongliveopensola...@nedharvey.com> wrote: > > Question:? Is it possible, or can it easily become possible, to periodically > > dedup a pool instead of keeping dedup running all the time?? It is easy to > > I think it's been discussed before, and the conclusion is that it > would require bp_rewrite.
Yes, and possibly would require more of bp_rewrite than any other use case (ie, a more complex bp_rewrite). > Offline (or deferred) dedup certainly seems more attractive given the > current real-time performance. I'm not so sure. Or, rather, if it were there and available now, I'm sure some people would use it and prefer it for their circumstances. Nothing comes for free, in terms of development or operational complexity. It seems attractive for retroactively recovering space, as a rare operation, while maintaining snapshot integrity (and not taking everything offline for a send|recv). But you want to be sure you can carry the cost of that space saving. Once your data is dedup'ed, by whatever means, access to it is the same. You need enough memory+l2arc to indirect references via DDT. If this is your performance problem today, it will not be helped much by deferral. Reads will still have the same issue, as will the deferred dedup write workload (with more work overall). But I don't think it solves the core overhead of freeing deduped blocks, and once that's no longer a problem for you, neither is the synchronous dedup. Plus, if you're just on the edge, that can be deferred as noted previously, though that's not a very nice place to be. I tend to think that background/deferred dedup is a task more similar to HSM / archival type activities, that will involve some level of application responsibility as well as fs-level assistance hooks. For all the work it would involve, I'd like to get more value than just a few saved disk blocks. -- Dan.
pgpSDYMJroHHU.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
