> From: Brandon High [mailto:bh...@freaks.com] > Sent: Thursday, April 28, 2011 5:33 PM > > On Wed, Apr 27, 2011 at 9:26 PM, Edward Ned Harvey > <opensolarisisdeadlongliveopensola...@nedharvey.com> wrote: > > Correct me if I'm wrong, but the dedup sha256 checksum happens in > addition > > to (not instead of) the fletcher2 integrity checksum. So after bootup, > > My understanding is that enabling dedup forces sha256. > > "The default checksum used for deduplication is sha256 (subject to > change). When dedup is enabled, the dedup checksum algorithm overrides > the checksum property."
Interesting. So it would seem, that the DDT probably does get populated into ARC, simply by having read something from disk. That was one important consequence in discussion ... (DDT does not only get populated into ARC during writes.) PS. I'm only drawing conclusions here, so please tell me I'm wrong if I'm wrong somehow. The other important consequence, not yet answered: When a block is scheduled to be written, system performs checksum, and looks for a matching entry in DDT in ARC/L2ARC. In the event of an ARC/L2ARC cache miss for a DDT entry which actually exists, the system will need to perform a number of small disk reads in order to fetch the DDT entry from disk. Correct? I figure at least one, probably more than one, read to locate the entry on disk, and then another read to actually read the entry. After this, the system knows there is a checksum match between the block waiting to be written, and another block that's already on disk, and it could possibly have to do yet another read for verification, before it is able to finally do the write. Right? _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
