On Thu, May 26, 2011 at 07:38:05AM -0400, Edward Ned Harvey wrote: > > From: Daniel Carosone [mailto:d...@geek.com.au] > > Sent: Wednesday, May 25, 2011 10:10 PM > > > > These are additional > > iops that dedup creates, not ones that it substitutes for others in > > roughly equal number. > > Hey ZFS developers - Of course there are many ways to possibly address these > issues. Tweaking ARC prioritization and the like... Has anybody considered > the possibility of making an option to always keep DDT on a specific vdev? > Presumably a nonvolatile mirror with very fast iops. It is likely a lot of > people already have cache devices present... Perhaps a property could be > set, which would store the DDT exclusively on that device. Naturally there > are implications - you would need to recommend mirroring the device, which > you can't do, so maybe we're talking about slicing the cache device... As I > said, a lot of ways to address the issue.
I think l2arc persistence will just about cover that nicely, perhaps in combination with some smarter auto-tuning for arc percentages with large DDT. The writes are async, and aren't so much a problem in themselves other than that they can get in the way of other more important things. The best thing you can do with them is spread them as widely as possible, rather than bottlenecking specific devices/channels/etc. If you have a capacity shortfall overall, either you make the other things faster in preference (zil, nv write cache, more arc for reads) or you make the whole pool faster for iops (different layout, more spindles) or you limit dedup usage within your capacity. Another thing that can happen is that you have enough other sync writes going on that DDT writes lag behind and delay the txg close. In this case, the same solutions above apply, as does judicious use of "sync=disabled" to allow more of the writes to be async. > Both the necessity to read & write the primary storage pool... That's very > hurtful. And even with infinite ram, it's going to be unavoidable for > things like destroying snapshots, or anything at all you ever want to do > after a reboot. Yeah, again, persistent l2arc helps the post-reboot case. With infinite ram, I'm not sure I'd have much use for dedup :) -- Dan.
pgpqUsz7d3iF6.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
