On Sun, Dec 11, 2011 at 04:04:37PM +0400, Jim Klimov wrote: > I would not be surprised to see that there is some disk IO > adding delays for the second case (read of a deduped file > "clone"), because you still have to determine references > to this second file's blocks, and another path of on-disk > blocks might lead to it from a separate inode in a separate > dataset (or I might be wrong). Reading this second path of > pointers to the same cached data blocks might decrease speed > a little.
As I said, ZFS reading path involves no dedup code. No at all. The proof would be being able to boot from ZFS with dedup turned on eventhough ZFS boot code has 0 dedup code in it. Another proof would be ZFS source code. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com
pgpOdlii40IHg.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
