Kjetil Torgrim Homme wrote:
Note also that the compress/encrypt/checksum and the dedup are
separate pipeline stages so while dedup is happening for block N block
N+1 can be getting transformed - so this is designed to take advantage
of multiple scheduling units (threads,cpus,cores etc).
nice. are all of them separate stages, or are compress/encrypt/checksum
done as one stage?
Originally compress, encrypt, checksum were all separate stages in the
zio pipeline they are now all one stage ZIO_WRITE_BP_INIT for the write
case and ZIO_READ_BP_INIT for the read case.
Also if you place a block in an unencrypted dataset that happens to
match the ciphertext in an encrypted dataset they won't dedup either
(you need to understand what I've done with the AES CCM/GCM MAC and
the zio_chksum_t field in the blkptr_t and how that is used by dedup
to see why).
wow, I didn't think of that problem. did you get bitten by wrongful
dedup during testing with image files? :-)
No I didn't see the problem in reality I just thought about it in as a
possible risk that needed to be addressed.
Solving it didn't actually require me to do any additional work because
ZFS uses a separate table for each checksum algorithm anyway and the
checksum algorithm for encrypted datasets is listed as sha256+mac not
sha256. It was nice that I didn't have to write more code to solve the
problem but it may not have been that way.
--
Darren J Moffat
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
