On 18.06.19 г. 17:15 ч., David Sterba wrote:
> We don't use the plain key for any on-disk operations so there's no
> requirement for the member order. As the offset is a u64 that should be
> on an 8byte aligned address, this can generate ineffective code on
> strict alignment architectures and can potentially hurt even on others
> (cross-cacheline access).
>
> The resulting asm code on x86_64 only differes in the offset, no significant
> change in size of the object size.
>
> The alignment of the structure is unchanged.
>
> Signed-off-by: David Sterba <dste...@suse.com>
> ---
> include/uapi/linux/btrfs_tree.h | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/btrfs_tree.h b/include/uapi/linux/btrfs_tree.h
> index aff1356c2bb8..9ca7adcf3b7f 100644
> --- a/include/uapi/linux/btrfs_tree.h
> +++ b/include/uapi/linux/btrfs_tree.h
> @@ -342,10 +342,17 @@ struct btrfs_disk_key {
> __le64 offset;
> } __attribute__ ((__packed__));
>
> +/*
> + * NOTE: this structure does not match the on-disk format of key and must be
> + * converted with the right helpers. The btrfs_key is for in-memory use and
> the
> + * members are reordered for better alignment. It's still packed as it's
> never
> + * used in arrays and the extra alignment would consume stack space in
> + * functions.
> + */
Since packing is only used as a "space optimisation" as far as I
understand it, I think the comment above btrfs_disk_key could be
modified such that the last sentence is perhahps removed?
> struct btrfs_key {
> __u64 objectid;
> - __u8 type;
> __u64 offset;
> + __u8 type;
> } __attribute__ ((__packed__));
>
> struct btrfs_dev_item {
>
