search for: blkptr_t

Hi All, I am looking at trying to understand the conceptual model of how data is grouped and partitioned within a storge pool. In looking at the on disk document that Tabriz sent out a few weeks ago I see that object sets are the grouping which ZFS uses to group objects that are related. Specifially to aid in format and layout of like objects in to a set. So, for example 1 potential object

...ot;gzip-7", 0}, /* ZIO_COMPRESS_GZIP_7 */ + {"gzip-8", 0}, /* ZIO_COMPRESS_GZIP_8 */ + {"gzip-9", 0}, /* ZIO_COMPRESS_GZIP_9 */ + {"zle", 0}, /* ZIO_COMPRESS_ZLE */ + {"lz4", lz4_decompress} /* ZIO_COMPRESS_LZ4 */ }; static int zio_read_data(blkptr_t *bp, void *buf, char *stack); @@ -80,8 +97,8 @@ static int zio_read_data(blkptr_t *bp, v static int zfs_bcmp(const void *s1, const void *s2, size_t n) { - const uint8_t *ps1 = s1; - const uint8_t *ps2 = s2; + const uchar_t *ps1 = s1; + const uchar_t *ps2 = s2; if (s1 != s2 && n != 0)...

Line 71 of http://cvs.opensolaris.org/source/xref/on/usr/src/uts/common/fs/zfs/sys/dsl_dataset.h#dsl_dataset_phys says uint64_t ds_pad[8]; /* pad out to 256 bytes for good measure */ But that padding actually increases dsl_dataset_phys to 320 bytes total; the structure is already 256 bytes without the padding. This message posted from opensolaris.org

Hello all, I am not sure my original mail got through to the list (I haven''t received it back), so I attach it below. Anyhow, now I have a saved kernel crash dump of the system panicking when it tries to - I believe - deferred-release the corrupted deduped blocks which are no longer referenced by the userdata/blockpointer tree. As I previously wrote in my thread on unfixeable

Deduplication was committed last night by Mr. Bonwick: > Log message: > PSARC 2009/571 ZFS Deduplication Properties > 6677093 zfs should have dedup capability http://mail.opensolaris.org/pipermail/onnv-notify/2009-November/010683.html Via c0t0d0s0.org.

For the encryption functionality in the ZFS filesystem we use AES in CCM or GCM mode at the block level to provide confidentiality and authentication. There is also a SHA256 checksum per block (of the ciphertext) that forms a Merkle tree of all the blocks in the pool. Note that I have to store the full IV in the block. A block here is a ZFS block which is any power of two from 512 bytes to