CAP_MSG_FIXED_FIELDS mistery

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

I am trying to understand CAP_MSG_FIXED_FIELDS definition meaning.
Currently, we have the "mysterious" definition [1]:

#if IS_ENABLED(CONFIG_FS_ENCRYPTION)
#define CAP_MSG_FIXED_FIELDS (sizeof(struct ceph_mds_caps) + \
		      4 + 8 + 4 + 4 + 8 + 4 + 4 + 4 + 8 + 8 + 4 + 8 +
8 + 4 + 4 + 8)

<skipped>

#else
#define CAP_MSG_FIXED_FIELDS (sizeof(struct ceph_mds_caps) + \
		      4 + 8 + 4 + 4 + 8 + 4 + 4 + 4 + 8 + 8 + 4 + 8 +
8 + 4 + 4)

As far as I can see, this commit introduced the very first definition:

commit e20d258d73a8d565b729b6fc0290e060daabd8b8
Author: Yan, Zheng <zyan@xxxxxxxxxx>
Date:   Fri Nov 14 22:39:13 2014 +0800

    ceph: flush inline version
    
    After converting inline data to normal data, client need to flush
    the new i_inline_version (CEPH_INLINE_NONE) to MDS. This commit
makes
    cap messages (sent to MDS) contain inline_version and inline_data.
    Client always converts inline data to normal data before data
write,
    so the inline data length part is always zero.
    
    Signed-off-by: Yan, Zheng <zyan@xxxxxxxxxx>

	/* flock buffer size + inline version + inline data size */
	extra_len = 4 + 8 + 4;

Next commit adds another constant into the equation:

commit a2971c8ccb9bd7677a6c43cdbed9aacfef5e9f26
Author: Yan, Zheng <zyan@xxxxxxxxxx>
Date:   Wed Jun 10 11:09:32 2015 +0800

    ceph: send TID of the oldest pending caps flush to MDS
    
    According to this information, MDS can trim its completed caps
flush
    list (which is used to detect duplicated cap flush).
    
    Signed-off-by: Yan, Zheng <zyan@xxxxxxxxxx>

	/* flock buffer size + inline version + inline data size +
	 * osd_epoch_barrier + oldest_flush_tid */
	extra_len = 4 + 8 + 4 + 4 + 8;

This commit added another constants into the equation but comment
hasn't been updated:

commit 43b29673307387f7b939fceeedefd08ece13c41d
Author: Jeff Layton <jlayton@xxxxxxxxxx>
Date:   Thu Nov 10 07:42:05 2016 -0500

    ceph: update cap message struct version to 10
    
    The userland ceph has MClientCaps at struct version 10. This brings
the
    kernel up the same version.
    
    For now, all of the the new stuff is set to default values
including
    the flags field, which will be conditionally set in a later patch.
    
    Note that we don't need to set the change_attr and btime to
anything
    since we aren't currently setting the feature flag. The MDS should
    ignore those values.
    
    Signed-off-by: Jeff Layton <jlayton@xxxxxxxxxx>
    Reviewed-by: Yan, Zheng <zyan@xxxxxxxxxx>

	/* flock buffer size + inline version + inline data size +
	 * osd_epoch_barrier + oldest_flush_tid */
	extra_len = 4 + 8 + 4 + 4 + 8;
	extra_len = 4 + 8 + 4 + 4 + 8 + 4 + 4 + 4 + 8 + 8 + 4;

This commit introduced the dedicated definition for the whole equation:

commit 16d68903f56ae277446cc2d24ab18db835363eda
Author: Jeff Layton <jlayton@xxxxxxxxxx>
Date:   Mon Mar 30 07:20:27 2020 -0400

    ceph: break up send_cap_msg
    
    Push the allocation of the msg and the send into the caller. Rename
    the function to encode_cap_msg and make it void return.
    
    Signed-off-by: Jeff Layton <jlayton@xxxxxxxxxx>
    Signed-off-by: Ilya Dryomov <idryomov@xxxxxxxxx>


 * cap struct size + flock buffer size + inline version + inline data
size +
 * osd_epoch_barrier + oldest_flush_tid
 */

#define CAP_MSG_SIZE (sizeof(struct ceph_mds_caps) + \
		      4 + 8 + 4 + 4 + 8 + 4 + 4 + 4 + 8 + 8 + 4) 

Finally, this commit remove comment + CAP_MSG_SIZE, and introduces a
new definition without any comment:

commit 2d332d5bc424404911540006a8bb450fbb96b178
Author: Jeff Layton <jlayton@xxxxxxxxxx>
Date:   Mon Jul 27 10:16:09 2020 -0400

    ceph: fscrypt_auth handling for ceph
    
    Most fscrypt-enabled filesystems store the crypto context in an
xattr,
    but that's problematic for ceph as xatts are governed by the XATTR
cap,
    but we really want the crypto context as part of the AUTH cap.
    
    Because of this, the MDS has added two new inode metadata fields:
    fscrypt_auth and fscrypt_file. The former is used to hold the
crypto
    context, and the latter is used to track the real file size.
    
    Parse new fscrypt_auth and fscrypt_file fields in inode traces. For
now,
    we don't use fscrypt_file, but fscrypt_auth is used to hold the
fscrypt
    context.
    
    Allow the client to use a setattr request for setting the
fscrypt_auth
    field. Since this is not a standard setattr request from the VFS,
we add
    a new field to __ceph_setattr that carries ceph-specific inode
attrs.
    
    Have the set_context op do a setattr that sets the fscrypt_auth
value,
    and get_context just return the contents of that field (since it
should
    always be available).
    
    Signed-off-by: Jeff Layton <jlayton@xxxxxxxxxx>
    Reviewed-by: Xiubo Li <xiubli@xxxxxxxxxx>
    Reviewed-and-tested-by: Luís Henriques <lhenriques@xxxxxxx>
    Reviewed-by: Milind Changire <mchangir@xxxxxxxxxx>
    Signed-off-by: Ilya Dryomov <idryomov@xxxxxxxxx>

#define CAP_MSG_FIXED_FIELDS (sizeof(struct ceph_mds_caps) + \
		      4 + 8 + 4 + 4 + 8 + 4 + 4 + 4 + 8 + 8 + 4 + 8 +
8 + 4 + 4)

So, as far as I can follow:

4 + 8 + 4 + 4 + 8 means:

(1) flock buffer size -> 4
(2) inline version -> 8
(3) inline data size -> 4
(4) osd_epoch_barrier -> 4
(5) oldest_flush_tid -> 8

But what does it mean the rest of the formula: 4 + 4 + 4 + 8 + 8 + 4 +
8 + 8?

Thanks,
Slava.

[1]
https://elixir.bootlin.com/linux/v6.13-rc2/source/fs/ceph/caps.c#L1498






[Index of Archives]     [CEPH Users]     [Ceph Large]     [Ceph Dev]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux