> +#define BTRFS_DEDUP_HASH_SIZE 32 /* 256bit = 32 * 8bit */
> +#define BTRFS_DEDUP_HASH_LEN 4
> +
> +struct btrfs_dedup_hash_item {
> + /* FIXME: put a hash type field here */
> +
> + __le64 hash[BTRFS_DEDUP_HASH_LEN];
> +} __attribute__ ((__packed__));
The handling of hashes in this patch is a mess.
The inconsistent use of _SIZE, _LEN, and literal 4 and the u64 *s being
passed around is asking for mistakes to be made in the future. And I
don't think it's endian safe.
I think I'd have a struct that represents the native representation of
the tree item. Something like:
struct btrfs_dedup_hash {
u64 key_value;
u8 algo;
u8 len;
u8 bytes[0];
}
You can then have helpers that generate that from either the cryptolib
transformation of dedup regions or to and from the tree items. The
bytes (and the tree item payload) wouldn't need to have the hash bytes
that are stored up in the key.
- z
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
