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
pgpNepBs6v1MX.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
