On Mon, Dec 12, 2011 at 08:30:56PM +0400, Jim Klimov wrote:
> 2011-12-12 19:03, Pawel Jakub Dawidek пишет:
> > As I said, ZFS reading path involves no dedup code. No at all.
> I am not sure if we contradicted each other ;)
> What I meant was that the ZFS reading path involves reading
> logical data blocks at some point, consulting the cache(s)
> if the block is already cached (and up-to-date). These blocks
> are addressed by some unique ID, and now with dedup there are
> several pointers to same block.
> So, basically, reading a file involves reading ZFS metadata,
> determining data block IDs, fetching them from disk or cache.
> Indeed, this does not need to be dedup-aware; but if the other
> chain of metadata blocks points to same data or metadata blocks
> which were already cached (for whatever reason, not limited to
> dedup) - this is where the read-speed boost appears.
> Likewise, if some blocks are not cached, such as metadata
> needed to determine the second file's block IDs, this incurs
> disk IOs and may decrease overall speed.

Ok, you are right, although in this test, I believe metadata of the
other file was already prefetched. I'm using this box for something else
now, so can't retest, but the procedure is so easy that everyone is
welcome to try it:)

Pawel Jakub Dawidek                       http://www.wheelsystems.com
FreeBSD committer                         http://www.FreeBSD.org
Am I Evil? Yes, I Am!                     http://yomoli.com

Attachment: pgpNepBs6v1MX.pgp
Description: PGP signature

zfs-discuss mailing list

Reply via email to