[PATCH v2 0/8] btrfs-progs: fscrypt updates

[PATCH v2 0/8] btrfs-progs: fscrypt updates

[Daniel Vacek]

This series is a rebase of an older set of fscrypt related changes from
Sweet Tea Dorminy and Josef Bacik found here:
https://github.com/josefbacik/btrfs-progs/tree/fscrypt

Since then the on-disk format changed and parts of the series had to be
reworked. Now it works with the v7 of kernel changes.

Particularly the encryption context is now stored as dedicated item and
not glued onto extent data item.

Also it was missing to recognize the ENCRYPT inode item flag. So now
it's properly parsed.

It passed all my tests. Hopefully nothing blows. Enjoy testing.

Daniel Vacek (1):
  btrfs-progs: recognize ENCRYPT inode item flag

Josef Bacik (1):
  btrfs-progs: check: fix max inline extent size

Sweet Tea Dorminy (6):
  btrfs-progs: add new FEATURE_INCOMPAT_ENCRYPT flag
  btrfs-progs: start tracking extent encryption context info
  btrfs-progs: add inode encryption contexts
  btrfs-progs: print encryptin type field of file extents
  btrfs-progs: handle fscrypt context items
  btrfs-progs: check: update inline extent length checking

 check/main.c                    | 29 +++++++++++++++--------------
 kernel-shared/ctree.h           |  1 +
 kernel-shared/print-tree.c      | 23 +++++++++++++++++++++++
 kernel-shared/tree-checker.c    | 17 ++++++++++-------
 kernel-shared/uapi/btrfs.h      |  1 +
 kernel-shared/uapi/btrfs_tree.h | 11 +++++++++++
 libbtrfsutil/btrfs.h            |  1 +
 7 files changed, 62 insertions(+), 21 deletions(-)

-- 
2.53.0

[PATCH v2 1/8] btrfs-progs: check: fix max inline extent size

[Daniel Vacek]

From: Josef Bacik <josef@toxicpanda.com>

Fscrypt will use our entire inline extent range for symlinks, which
uncovered a bug in btrfs check where we set the maximum inline extent
size to

min(sectorsize - 1, BTRFS_MAX_INLINE_DATA_SIZE)

which isn't correct, we have always allowed sectorsize sized inline
extents, so fix check to use the correct maximum inline extent size.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Daniel Vacek <neelx@suse.com>
---
 check/main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/check/main.c b/check/main.c
index 5e29e2c5..dedb4db4 100644
--- a/check/main.c
+++ b/check/main.c
@@ -1720,7 +1720,7 @@ static int process_file_extent(struct btrfs_root *root,
 	u64 disk_bytenr = 0;
 	u64 extent_offset = 0;
 	u64 mask = gfs_info->sectorsize - 1;
-	u32 max_inline_size = min_t(u32, mask,
+	u32 max_inline_size = min_t(u32, gfs_info->sectorsize,
 				BTRFS_MAX_INLINE_DATA_SIZE(gfs_info));
 	u8 compression;
 	int extent_type;
-- 
2.53.0

[PATCH v2 2/8] btrfs-progs: add new FEATURE_INCOMPAT_ENCRYPT flag

[Daniel Vacek]

From: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>

Matches kernel change by the same name.

Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
Signed-off-by: Daniel Vacek <neelx@suse.com>
---
 kernel-shared/ctree.h      | 1 +
 kernel-shared/uapi/btrfs.h | 1 +
 libbtrfsutil/btrfs.h       | 1 +
 3 files changed, 3 insertions(+)

diff --git a/kernel-shared/ctree.h b/kernel-shared/ctree.h
index cb5a5f3f..177163f8 100644
--- a/kernel-shared/ctree.h
+++ b/kernel-shared/ctree.h
@@ -99,6 +99,7 @@ static inline u32 __BTRFS_LEAF_DATA_SIZE(u32 nodesize)
 	 BTRFS_FEATURE_INCOMPAT_ZONED |			\
 	 BTRFS_FEATURE_INCOMPAT_EXTENT_TREE_V2 |	\
 	 BTRFS_FEATURE_INCOMPAT_RAID_STRIPE_TREE |	\
+	 BTRFS_FEATURE_INCOMPAT_ENCRYPT |		\
 	 BTRFS_FEATURE_INCOMPAT_SIMPLE_QUOTA |		\
 	 BTRFS_FEATURE_INCOMPAT_REMAP_TREE)
 #else
diff --git a/kernel-shared/uapi/btrfs.h b/kernel-shared/uapi/btrfs.h
index a765fbc4..7144f3ba 100644
--- a/kernel-shared/uapi/btrfs.h
+++ b/kernel-shared/uapi/btrfs.h
@@ -359,6 +359,7 @@ _static_assert(sizeof(struct btrfs_ioctl_fs_info_args) == 1024);
 #define BTRFS_FEATURE_INCOMPAT_ZONED		(1ULL << 12)
 #define BTRFS_FEATURE_INCOMPAT_EXTENT_TREE_V2	(1ULL << 13)
 #define BTRFS_FEATURE_INCOMPAT_RAID_STRIPE_TREE (1ULL << 14)
+#define BTRFS_FEATURE_INCOMPAT_ENCRYPT		(1ULL << 15)
 #define BTRFS_FEATURE_INCOMPAT_SIMPLE_QUOTA	(1ULL << 16)
 #define BTRFS_FEATURE_INCOMPAT_REMAP_TREE	(1ULL << 17)
 
diff --git a/libbtrfsutil/btrfs.h b/libbtrfsutil/btrfs.h
index 47d9ebf8..eac42473 100644
--- a/libbtrfsutil/btrfs.h
+++ b/libbtrfsutil/btrfs.h
@@ -328,6 +328,7 @@ struct btrfs_ioctl_fs_info_args {
 #define BTRFS_FEATURE_INCOMPAT_ZONED		(1ULL << 12)
 #define BTRFS_FEATURE_INCOMPAT_EXTENT_TREE_V2	(1ULL << 13)
 #define BTRFS_FEATURE_INCOMPAT_RAID_STRIPE_TREE (1ULL << 14)
+#define BTRFS_FEATURE_INCOMPAT_ENCRYPT		(1ULL << 15)
 #define BTRFS_FEATURE_INCOMPAT_SIMPLE_QUOTA	(1ULL << 16)
 
 struct btrfs_ioctl_feature_flags {
-- 
2.53.0

[PATCH v2 3/8] btrfs-progs: start tracking extent encryption context info

[Daniel Vacek]

From: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>

This recapitulates the kernel change named 'btrfs: start tracking extent
encryption context info".

Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
Signed-off-by: Daniel Vacek <neelx@suse.com>
---
 kernel-shared/tree-checker.c    | 17 ++++++++++-------
 kernel-shared/uapi/btrfs_tree.h |  6 ++++++
 2 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/kernel-shared/tree-checker.c b/kernel-shared/tree-checker.c
index 5e716422..cd3d5d27 100644
--- a/kernel-shared/tree-checker.c
+++ b/kernel-shared/tree-checker.c
@@ -239,6 +239,8 @@ static int check_extent_data_item(struct extent_buffer *leaf,
 	u32 sectorsize = fs_info->sectorsize;
 	u32 item_size = btrfs_item_size(leaf, slot);
 	u64 extent_end;
+	u8 policy;
+	u8 fe_type;
 
 	if (unlikely(!IS_ALIGNED(key->offset, sectorsize))) {
 		file_extent_err(leaf, slot,
@@ -269,12 +271,12 @@ static int check_extent_data_item(struct extent_buffer *leaf,
 				SZ_4K);
 		return -EUCLEAN;
 	}
-	if (unlikely(btrfs_file_extent_type(leaf, fi) >=
-		     BTRFS_NR_FILE_EXTENT_TYPES)) {
+
+	fe_type = btrfs_file_extent_type(leaf, fi);
+	if (unlikely(fe_type >= BTRFS_NR_FILE_EXTENT_TYPES)) {
 		file_extent_err(leaf, slot,
 		"invalid type for file extent, have %u expect range [0, %u]",
-			btrfs_file_extent_type(leaf, fi),
-			BTRFS_NR_FILE_EXTENT_TYPES - 1);
+			fe_type, BTRFS_NR_FILE_EXTENT_TYPES - 1);
 		return -EUCLEAN;
 	}
 
@@ -290,10 +292,11 @@ static int check_extent_data_item(struct extent_buffer *leaf,
 			BTRFS_NR_COMPRESS_TYPES - 1);
 		return -EUCLEAN;
 	}
-	if (unlikely(btrfs_file_extent_encryption(leaf, fi))) {
+	policy = btrfs_file_extent_encryption(leaf, fi);
+	if (unlikely(policy >= BTRFS_NR_ENCRYPTION_TYPES)) {
 		file_extent_err(leaf, slot,
-			"invalid encryption for file extent, have %u expect 0",
-			btrfs_file_extent_encryption(leaf, fi));
+			"invalid encryption for file extent, have %u expect range [0, %u]",
+			policy, BTRFS_NR_ENCRYPTION_TYPES - 1);
 		return -EUCLEAN;
 	}
 	if (btrfs_file_extent_type(leaf, fi) == BTRFS_FILE_EXTENT_INLINE) {
diff --git a/kernel-shared/uapi/btrfs_tree.h b/kernel-shared/uapi/btrfs_tree.h
index 1ca63711..74d307f1 100644
--- a/kernel-shared/uapi/btrfs_tree.h
+++ b/kernel-shared/uapi/btrfs_tree.h
@@ -1072,6 +1072,12 @@ enum {
 	BTRFS_NR_FILE_EXTENT_TYPES = 3,
 };
 
+enum {
+	BTRFS_ENCRYPTION_NONE,
+	BTRFS_ENCRYPTION_FSCRYPT,
+	BTRFS_NR_ENCRYPTION_TYPES,
+};
+
 struct btrfs_file_extent_item {
 	/*
 	 * transaction id that created this extent
-- 
2.53.0

[PATCH v2 4/8] btrfs-progs: add inode encryption contexts

[Daniel Vacek]

From: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>

Recapitulates relevant parts of kernel change 'btrfs: add inode
encryption contexts'.

Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
Signed-off-by: Daniel Vacek <neelx@suse.com>
---
 kernel-shared/uapi/btrfs_tree.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/kernel-shared/uapi/btrfs_tree.h b/kernel-shared/uapi/btrfs_tree.h
index 74d307f1..45675dae 100644
--- a/kernel-shared/uapi/btrfs_tree.h
+++ b/kernel-shared/uapi/btrfs_tree.h
@@ -168,6 +168,8 @@
 #define BTRFS_VERITY_DESC_ITEM_KEY	36
 #define BTRFS_VERITY_MERKLE_ITEM_KEY	37
 
+#define BTRFS_FSCRYPT_CTXT_ITEM_KEY	41
+
 #define BTRFS_ORPHAN_ITEM_KEY		48
 /* reserve 2-15 close to the inode for later flexibility */
 
@@ -428,6 +430,7 @@ static inline __u8 btrfs_dir_flags_to_ftype(__u8 flags)
 #define BTRFS_INODE_NOATIME		(1U << 9)
 #define BTRFS_INODE_DIRSYNC		(1U << 10)
 #define BTRFS_INODE_COMPRESS		(1U << 11)
+#define BTRFS_INODE_ENCRYPT		(1U << 12)
 
 #define BTRFS_INODE_ROOT_ITEM_INIT	(1U << 31)
 
@@ -444,6 +447,7 @@ static inline __u8 btrfs_dir_flags_to_ftype(__u8 flags)
 	 BTRFS_INODE_NOATIME |						\
 	 BTRFS_INODE_DIRSYNC |						\
 	 BTRFS_INODE_COMPRESS |						\
+	 BTRFS_INODE_ENCRYPT |						\
 	 BTRFS_INODE_ROOT_ITEM_INIT)
 
 #define BTRFS_INODE_RO_VERITY		(1U << 0)
-- 
2.53.0

[PATCH v2 5/8] btrfs-progs: print encryptin type field of file extents

[Daniel Vacek]

From: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>

Encrypted file extents now have the 'encryption' field set to an
encryption type.  Let's print it.

Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
Signed-off-by: Daniel Vacek <neelx@suse.com>
---
 check/main.c               | 1 -
 kernel-shared/print-tree.c | 2 ++
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/check/main.c b/check/main.c
index dedb4db4..a32247b3 100644
--- a/check/main.c
+++ b/check/main.c
@@ -1778,7 +1778,6 @@ static int process_file_extent(struct btrfs_root *root,
 			rec->errors |= I_ERR_BAD_FILE_EXTENT;
 		if (extent_type == BTRFS_FILE_EXTENT_PREALLOC &&
 		    (btrfs_file_extent_compression(eb, fi) ||
-		     btrfs_file_extent_encryption(eb, fi) ||
 		     btrfs_file_extent_other_encoding(eb, fi)))
 			rec->errors |= I_ERR_BAD_FILE_EXTENT;
 		if (compression && rec->nodatasum)
diff --git a/kernel-shared/print-tree.c b/kernel-shared/print-tree.c
index 0afa3696..159f0825 100644
--- a/kernel-shared/print-tree.c
+++ b/kernel-shared/print-tree.c
@@ -471,6 +471,8 @@ static void print_file_extent_item(struct extent_buffer *eb,
 	printf("\t\textent compression %hhu (%s)\n",
 			btrfs_file_extent_compression(eb, fi),
 			compress_str);
+	printf("\t\textent encryption %hhu\n",
+			btrfs_file_extent_encryption(eb, fi));
 }
 
 /* Caller should ensure sizeof(*ret) >= 16("DATA|TREE_BLOCK") */
-- 
2.53.0

[PATCH v2 6/8] btrfs-progs: handle fscrypt context items

[Daniel Vacek]

From: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>

Encrypted inodes have a new associated item, the fscrypt context, which
can be printed as a pure hex string in dump-tree.

Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
Signed-off-by: Daniel Vacek <neelx@suse.com>
---
 check/main.c                    |  2 ++
 kernel-shared/print-tree.c      | 20 ++++++++++++++++++++
 kernel-shared/uapi/btrfs_tree.h |  3 ++-
 3 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/check/main.c b/check/main.c
index a32247b3..2df55edc 100644
--- a/check/main.c
+++ b/check/main.c
@@ -1896,6 +1896,8 @@ static int process_one_leaf(struct btrfs_root *root, struct extent_buffer *eb,
 			break;
 		case BTRFS_VERITY_DESC_ITEM_KEY:
 		case BTRFS_VERITY_MERKLE_ITEM_KEY:
+		case BTRFS_FSCRYPT_INODE_CTX_KEY:
+		case BTRFS_FSCRYPT_CTX_KEY:
 			break;
 		default:
 			error("unknown key (%llu %u %llu) found in leaf %llu",
diff --git a/kernel-shared/print-tree.c b/kernel-shared/print-tree.c
index 159f0825..d68398e9 100644
--- a/kernel-shared/print-tree.c
+++ b/kernel-shared/print-tree.c
@@ -117,6 +117,20 @@ static void print_dir_item(struct extent_buffer *eb, u32 size,
 	}
 }
 
+static void print_fscrypt_context(struct extent_buffer *eb, int slot)
+{
+	int i;
+	unsigned long ptr = btrfs_item_ptr_offset(eb, slot);
+	u32 item_size = btrfs_item_size(eb, slot);
+	u8 ctx_buf[item_size];
+
+	read_extent_buffer(eb, ctx_buf, ptr, item_size);
+	printf("\t\tvalue: ");
+	for(i = 0; i < item_size; i++)
+		printf("%02x", ctx_buf[i]);
+	printf("\n");
+}
+
 static void print_inode_extref_item(struct extent_buffer *eb, u32 size,
 		struct btrfs_inode_extref *extref)
 {
@@ -740,6 +754,8 @@ void print_key_type(FILE *stream, u64 objectid, u8 type)
 		[BTRFS_DIR_LOG_ITEM_KEY]	= "DIR_LOG_ITEM",
 		[BTRFS_DIR_LOG_INDEX_KEY]	= "DIR_LOG_INDEX",
 		[BTRFS_XATTR_ITEM_KEY]		= "XATTR_ITEM",
+		[BTRFS_FSCRYPT_INODE_CTX_KEY]   = "FSCRYPT_INODE_CTX",
+		[BTRFS_FSCRYPT_CTX_KEY]         = "FSCRYPT_CTX",
 		[BTRFS_VERITY_DESC_ITEM_KEY]	= "VERITY_DESC_ITEM",
 		[BTRFS_VERITY_MERKLE_ITEM_KEY]	= "VERITY_MERKLE_ITEM",
 		[BTRFS_ORPHAN_ITEM_KEY]		= "ORPHAN_ITEM",
@@ -1556,6 +1572,10 @@ void __btrfs_print_leaf(struct extent_buffer *eb, unsigned int mode)
 		case BTRFS_XATTR_ITEM_KEY:
 			print_dir_item(eb, item_size, ptr);
 			break;
+		case BTRFS_FSCRYPT_INODE_CTX_KEY:
+		case BTRFS_FSCRYPT_CTX_KEY:
+			print_fscrypt_context(eb, i);
+			break;
 		case BTRFS_DIR_LOG_INDEX_KEY:
 		case BTRFS_DIR_LOG_ITEM_KEY: {
 			struct btrfs_dir_log_item *dlog;
diff --git a/kernel-shared/uapi/btrfs_tree.h b/kernel-shared/uapi/btrfs_tree.h
index 45675dae..b4532237 100644
--- a/kernel-shared/uapi/btrfs_tree.h
+++ b/kernel-shared/uapi/btrfs_tree.h
@@ -168,7 +168,8 @@
 #define BTRFS_VERITY_DESC_ITEM_KEY	36
 #define BTRFS_VERITY_MERKLE_ITEM_KEY	37
 
-#define BTRFS_FSCRYPT_CTXT_ITEM_KEY	41
+#define BTRFS_FSCRYPT_INODE_CTX_KEY	41
+#define BTRFS_FSCRYPT_CTX_KEY		42
 
 #define BTRFS_ORPHAN_ITEM_KEY		48
 /* reserve 2-15 close to the inode for later flexibility */
-- 
2.53.0

[PATCH v2 7/8] btrfs-progs: check: update inline extent length checking

[Daniel Vacek]

From: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>

As part of the encryption changes, encrypted inline file extents record
their actual data length in ram_bytes, like compressed inline file
extents, while the item's length records the actual size. As such,
encrypted inline extents must be treated like compressed ones for
inode length consistency checking.

Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
Signed-off-by: Daniel Vacek <neelx@suse.com>
---
 check/main.c | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/check/main.c b/check/main.c
index 2df55edc..4902cbd9 100644
--- a/check/main.c
+++ b/check/main.c
@@ -1722,7 +1722,7 @@ static int process_file_extent(struct btrfs_root *root,
 	u64 mask = gfs_info->sectorsize - 1;
 	u32 max_inline_size = min_t(u32, gfs_info->sectorsize,
 				BTRFS_MAX_INLINE_DATA_SIZE(gfs_info));
-	u8 compression;
+	u8 compression, encryption;
 	int extent_type;
 	int ret;
 
@@ -1747,25 +1747,25 @@ static int process_file_extent(struct btrfs_root *root,
 	fi = btrfs_item_ptr(eb, slot, struct btrfs_file_extent_item);
 	extent_type = btrfs_file_extent_type(eb, fi);
 	compression = btrfs_file_extent_compression(eb, fi);
+	encryption = btrfs_file_extent_encryption(eb, fi);
 
 	if (extent_type == BTRFS_FILE_EXTENT_INLINE) {
-		num_bytes = btrfs_file_extent_ram_bytes(eb, fi);
-		if (num_bytes == 0)
+		u64 num_decoded_bytes = btrfs_file_extent_ram_bytes(eb, fi);
+		u64 num_disk_bytes =  btrfs_file_extent_inline_item_len(eb, slot);
+		if (num_decoded_bytes == 0)
 			rec->errors |= I_ERR_BAD_FILE_EXTENT;
-		if (compression) {
-			if (btrfs_file_extent_inline_item_len(eb, slot) >
-			    max_inline_size ||
-			    num_bytes > gfs_info->sectorsize)
+		if (compression || encryption) {
+			if (num_disk_bytes > max_inline_size ||
+			    num_decoded_bytes > gfs_info->sectorsize)
 				rec->errors |= I_ERR_FILE_EXTENT_TOO_LARGE;
 		} else {
-			if (num_bytes > max_inline_size)
+			if (num_decoded_bytes > max_inline_size)
 				rec->errors |= I_ERR_FILE_EXTENT_TOO_LARGE;
-			if (btrfs_file_extent_inline_item_len(eb, slot) !=
-			    num_bytes)
+			if (num_disk_bytes != num_decoded_bytes)
 				rec->errors |= I_ERR_INLINE_RAM_BYTES_WRONG;
 		}
-		rec->found_size += num_bytes;
-		num_bytes = (num_bytes + mask) & ~mask;
+		rec->found_size += num_decoded_bytes;
+		num_bytes = (num_decoded_bytes + mask) & ~mask;
 	} else if (extent_type == BTRFS_FILE_EXTENT_REG ||
 		   extent_type == BTRFS_FILE_EXTENT_PREALLOC) {
 		num_bytes = btrfs_file_extent_num_bytes(eb, fi);
-- 
2.53.0

[PATCH v2 8/8] btrfs-progs: recognize ENCRYPT inode item flag

[Daniel Vacek]

Signed-off-by: Daniel Vacek <neelx@suse.com>
---
 kernel-shared/print-tree.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel-shared/print-tree.c b/kernel-shared/print-tree.c
index d68398e9..106708ef 100644
--- a/kernel-shared/print-tree.c
+++ b/kernel-shared/print-tree.c
@@ -1011,6 +1011,7 @@ static struct readable_flag_entry inode_flags_array[] = {
 	DEF_INODE_FLAG_ENTRY(NOATIME),
 	DEF_INODE_FLAG_ENTRY(DIRSYNC),
 	DEF_INODE_FLAG_ENTRY(COMPRESS),
+	DEF_INODE_FLAG_ENTRY(ENCRYPT),
 	DEF_INODE_FLAG_ENTRY(ROOT_ITEM_INIT),
 };
 static const int inode_flags_num = ARRAY_SIZE(inode_flags_array);
-- 
2.53.0

Re: [PATCH v2 1/8] btrfs-progs: check: fix max inline extent size

[Qu Wenruo]

在 2026/6/25 02:21, Daniel Vacek 写道:
> From: Josef Bacik <josef@toxicpanda.com>
> 
> Fscrypt will use our entire inline extent range for symlinks, which
> uncovered a bug in btrfs check where we set the maximum inline extent
> size to
> 
> min(sectorsize - 1, BTRFS_MAX_INLINE_DATA_SIZE)
> 
> which isn't correct, we have always allowed sectorsize sized inline
> extents, so fix check to use the correct maximum inline extent size.

No, we only allow sector sized inline extent when it is compressed.
The de-compressed size can be sector sized, but the compressed size 
still can not reach sector size.

So this doesn't seems correct to me.

> 
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
> Signed-off-by: Daniel Vacek <neelx@suse.com>
> ---
>   check/main.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/check/main.c b/check/main.c
> index 5e29e2c5..dedb4db4 100644
> --- a/check/main.c
> +++ b/check/main.c
> @@ -1720,7 +1720,7 @@ static int process_file_extent(struct btrfs_root *root,
>   	u64 disk_bytenr = 0;
>   	u64 extent_offset = 0;
>   	u64 mask = gfs_info->sectorsize - 1;
> -	u32 max_inline_size = min_t(u32, mask,
> +	u32 max_inline_size = min_t(u32, gfs_info->sectorsize,
>   				BTRFS_MAX_INLINE_DATA_SIZE(gfs_info));
>   	u8 compression;
>   	int extent_type;

Re: [PATCH v2 5/8] btrfs-progs: print encryptin type field of file extents

[Qu Wenruo]

在 2026/6/25 02:21, Daniel Vacek 写道:
> From: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
> 
> Encrypted file extents now have the 'encryption' field set to an
> encryption type.  Let's print it.
> 
> Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
> Signed-off-by: Daniel Vacek <neelx@suse.com>
> ---
>   check/main.c               | 1 -
>   kernel-shared/print-tree.c | 2 ++
>   2 files changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/check/main.c b/check/main.c
> index dedb4db4..a32247b3 100644
> --- a/check/main.c
> +++ b/check/main.c
> @@ -1778,7 +1778,6 @@ static int process_file_extent(struct btrfs_root *root,
>   			rec->errors |= I_ERR_BAD_FILE_EXTENT;
>   		if (extent_type == BTRFS_FILE_EXTENT_PREALLOC &&
>   		    (btrfs_file_extent_compression(eb, fi) ||
> -		     btrfs_file_extent_encryption(eb, fi) ||

May I ask why preallocated file extent would have encryption value set?

My common sense says that encryption policy should only be set for 
regular file extents.

Thanks,
Qu

>   		     btrfs_file_extent_other_encoding(eb, fi)))
>   			rec->errors |= I_ERR_BAD_FILE_EXTENT;
>   		if (compression && rec->nodatasum)
> diff --git a/kernel-shared/print-tree.c b/kernel-shared/print-tree.c
> index 0afa3696..159f0825 100644
> --- a/kernel-shared/print-tree.c
> +++ b/kernel-shared/print-tree.c
> @@ -471,6 +471,8 @@ static void print_file_extent_item(struct extent_buffer *eb,
>   	printf("\t\textent compression %hhu (%s)\n",
>   			btrfs_file_extent_compression(eb, fi),
>   			compress_str);
> +	printf("\t\textent encryption %hhu\n",
> +			btrfs_file_extent_encryption(eb, fi));
>   }
>   
>   /* Caller should ensure sizeof(*ret) >= 16("DATA|TREE_BLOCK") */

Re: [PATCH v2 1/8] btrfs-progs: check: fix max inline extent size

[Daniel Vacek]

On Fri, 26 Jun 2026 at 01:41, Qu Wenruo <wqu@suse.com> wrote:
> 在 2026/6/25 02:21, Daniel Vacek 写道:
> > From: Josef Bacik <josef@toxicpanda.com>
> >
> > Fscrypt will use our entire inline extent range for symlinks, which
> > uncovered a bug in btrfs check where we set the maximum inline extent
> > size to
> >
> > min(sectorsize - 1, BTRFS_MAX_INLINE_DATA_SIZE)
> >
> > which isn't correct, we have always allowed sectorsize sized inline
> > extents, so fix check to use the correct maximum inline extent size.
>
> No, we only allow sector sized inline extent when it is compressed.
> The de-compressed size can be sector sized, but the compressed size
> still can not reach sector size.
>
> So this doesn't seems correct to me.

With encryption it's the other way around. Even shorter data (symlink
path) is always padded to multiple of the cipher block size (16 bytes
with AES). Inlining a full sector size is perfectly valid. The dump
from my test looks like this:

~~~
    item 45 key (290 DIR_ITEM 3363472967) itemoff 11425 itemsize 62
        location key (300 INODE_ITEM 0) type SYMLINK
        transid 14 data_len 0 name_len 32
        name: \243\365@;\312\321\240\367\377\234_{\245\vW\
\035\rS\222ryN\323\031g\243\nt3\321+

    item 58 key (290 DIR_INDEX 11) itemoff 10077 itemsize 62
        location key (300 INODE_ITEM 0) type SYMLINK
        transid 14 data_len 0 name_len 32
        name: \243\365@;\312\321\240\367\377\234_{\245\vW\
\035\rS\222ryN\323\031g\243\nt3\321+

    item 86 key (300 INODE_ITEM 0) itemoff 7197 itemsize 160
        generation 14 transid 14 size 4096 nbytes 4096
        block group 0 mode 120777 links 1 uid 0 gid 0 rdev 0
        sequence 1829 flags 0x1000(ENCRYPT)
        atime 1782916271.8000000 (2026-07-01 16:31:11)
        ctime 1782916271.8000000 (2026-07-01 16:31:11)
        mtime 1782916271.8000000 (2026-07-01 16:31:11)
        otime 1782916271.8000000 (2026-07-01 16:31:11)
    item 87 key (300 INODE_REF 290) itemoff 7155 itemsize 42
        index 11 namelen 32 name:
\243\365@;\312\321\240\367\377\234_{\245\vW\
\035\rS\222ryN\323\031g\243\nt3\321+
    item 88 key (300 FSCRYPT_INODE_CTX 0) itemoff 7115 itemsize 40
        value: 02010403000000005f0642cd89f66ce3ed930fe3ac518b7381bcd7600f7ae1f08195bda44461ed5d
    item 89 key (300 EXTENT_DATA 0) itemoff 2998 itemsize 4117
        generation 14 type 0 (inline)
        inline extent data size 4096 ram_bytes 4096 compression 0 (none)
~~~

Perhaps this would better be folded into patch 7?

Or do you rather mean special-casing for compression (with the limits
as you mentioned) and encryption (with full sector size allowed)?

--nX

> > Signed-off-by: Josef Bacik <josef@toxicpanda.com>
> > Signed-off-by: Daniel Vacek <neelx@suse.com>
> > ---
> >   check/main.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/check/main.c b/check/main.c
> > index 5e29e2c5..dedb4db4 100644
> > --- a/check/main.c
> > +++ b/check/main.c
> > @@ -1720,7 +1720,7 @@ static int process_file_extent(struct btrfs_root *root,
> >       u64 disk_bytenr = 0;
> >       u64 extent_offset = 0;
> >       u64 mask = gfs_info->sectorsize - 1;
> > -     u32 max_inline_size = min_t(u32, mask,
> > +     u32 max_inline_size = min_t(u32, gfs_info->sectorsize,
> >                               BTRFS_MAX_INLINE_DATA_SIZE(gfs_info));
> >       u8 compression;
> >       int extent_type;
>

Re: [PATCH v2 5/8] btrfs-progs: print encryptin type field of file extents

[Daniel Vacek]

On Fri, 26 Jun 2026 at 01:50, Qu Wenruo <wqu@suse.com> wrote:
> 在 2026/6/25 02:21, Daniel Vacek 写道:
> > From: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
> >
> > Encrypted file extents now have the 'encryption' field set to an
> > encryption type.  Let's print it.
> >
> > Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
> > Signed-off-by: Daniel Vacek <neelx@suse.com>
> > ---
> >   check/main.c               | 1 -
> >   kernel-shared/print-tree.c | 2 ++
> >   2 files changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/check/main.c b/check/main.c
> > index dedb4db4..a32247b3 100644
> > --- a/check/main.c
> > +++ b/check/main.c
> > @@ -1778,7 +1778,6 @@ static int process_file_extent(struct btrfs_root *root,
> >                       rec->errors |= I_ERR_BAD_FILE_EXTENT;
> >               if (extent_type == BTRFS_FILE_EXTENT_PREALLOC &&
> >                   (btrfs_file_extent_compression(eb, fi) ||
> > -                  btrfs_file_extent_encryption(eb, fi) ||
>
> May I ask why preallocated file extent would have encryption value set?
>
> My common sense says that encryption policy should only be set for
> regular file extents.

There's nothing wrong with pre-allocating encrypted files. Unlike
compression, the exact size is known beforehand.

Simillar to NOCOW, the encrypted data will be stored with the next write.

--nX

> Thanks,
> Qu
>
> >                    btrfs_file_extent_other_encoding(eb, fi)))
> >                       rec->errors |= I_ERR_BAD_FILE_EXTENT;
> >               if (compression && rec->nodatasum)
> > diff --git a/kernel-shared/print-tree.c b/kernel-shared/print-tree.c
> > index 0afa3696..159f0825 100644
> > --- a/kernel-shared/print-tree.c
> > +++ b/kernel-shared/print-tree.c
> > @@ -471,6 +471,8 @@ static void print_file_extent_item(struct extent_buffer *eb,
> >       printf("\t\textent compression %hhu (%s)\n",
> >                       btrfs_file_extent_compression(eb, fi),
> >                       compress_str);
> > +     printf("\t\textent encryption %hhu\n",
> > +                     btrfs_file_extent_encryption(eb, fi));
> >   }
> >
> >   /* Caller should ensure sizeof(*ret) >= 16("DATA|TREE_BLOCK") */
>

Re: [PATCH v2 1/8] btrfs-progs: check: fix max inline extent size

[Qu Wenruo]

在 2026/7/2 01:17, Daniel Vacek 写道:
> On Fri, 26 Jun 2026 at 01:41, Qu Wenruo <wqu@suse.com> wrote:
>> 在 2026/6/25 02:21, Daniel Vacek 写道:
>>> From: Josef Bacik <josef@toxicpanda.com>
>>>
>>> Fscrypt will use our entire inline extent range for symlinks, which
>>> uncovered a bug in btrfs check where we set the maximum inline extent
>>> size to
>>>
>>> min(sectorsize - 1, BTRFS_MAX_INLINE_DATA_SIZE)
>>>
>>> which isn't correct, we have always allowed sectorsize sized inline
>>> extents, so fix check to use the correct maximum inline extent size.
>>
>> No, we only allow sector sized inline extent when it is compressed.
>> The de-compressed size can be sector sized, but the compressed size
>> still can not reach sector size.
>>
>> So this doesn't seems correct to me.
> 
> With encryption it's the other way around. Even shorter data (symlink
> path) is always padded to multiple of the cipher block size (16 bytes
> with AES). Inlining a full sector size is perfectly valid. The dump
> from my test looks like this:
> 
> ~~~
>      item 45 key (290 DIR_ITEM 3363472967) itemoff 11425 itemsize 62
>          location key (300 INODE_ITEM 0) type SYMLINK
>          transid 14 data_len 0 name_len 32
>          name: \243\365@;\312\321\240\367\377\234_{\245\vW\
> \035\rS\222ryN\323\031g\243\nt3\321+
> 
>      item 58 key (290 DIR_INDEX 11) itemoff 10077 itemsize 62
>          location key (300 INODE_ITEM 0) type SYMLINK
>          transid 14 data_len 0 name_len 32
>          name: \243\365@;\312\321\240\367\377\234_{\245\vW\
> \035\rS\222ryN\323\031g\243\nt3\321+
> 
>      item 86 key (300 INODE_ITEM 0) itemoff 7197 itemsize 160
>          generation 14 transid 14 size 4096 nbytes 4096
>          block group 0 mode 120777 links 1 uid 0 gid 0 rdev 0
>          sequence 1829 flags 0x1000(ENCRYPT)
>          atime 1782916271.8000000 (2026-07-01 16:31:11)
>          ctime 1782916271.8000000 (2026-07-01 16:31:11)
>          mtime 1782916271.8000000 (2026-07-01 16:31:11)
>          otime 1782916271.8000000 (2026-07-01 16:31:11)
>      item 87 key (300 INODE_REF 290) itemoff 7155 itemsize 42
>          index 11 namelen 32 name:
> \243\365@;\312\321\240\367\377\234_{\245\vW\
> \035\rS\222ryN\323\031g\243\nt3\321+
>      item 88 key (300 FSCRYPT_INODE_CTX 0) itemoff 7115 itemsize 40
>          value: 02010403000000005f0642cd89f66ce3ed930fe3ac518b7381bcd7600f7ae1f08195bda44461ed5d
>      item 89 key (300 EXTENT_DATA 0) itemoff 2998 itemsize 4117
>          generation 14 type 0 (inline)
>          inline extent data size 4096 ram_bytes 4096 compression 0 (none)
> ~~~
> 
> Perhaps this would better be folded into patch 7?
> 
> Or do you rather mean special-casing for compression (with the limits
> as you mentioned) and encryption (with full sector size allowed)?

In that case, I'd prefer the limit to be only loosen for encryption.

So we won't have unexpected non-encrypted inlined extents to reach the 
limit.

BTW, it would be great if the progs dump-tree also prints encryption 
value for the inlined extent.

Thanks,
Qu

> 
> --nX
> 
>>> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
>>> Signed-off-by: Daniel Vacek <neelx@suse.com>
>>> ---
>>>    check/main.c | 2 +-
>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/check/main.c b/check/main.c
>>> index 5e29e2c5..dedb4db4 100644
>>> --- a/check/main.c
>>> +++ b/check/main.c
>>> @@ -1720,7 +1720,7 @@ static int process_file_extent(struct btrfs_root *root,
>>>        u64 disk_bytenr = 0;
>>>        u64 extent_offset = 0;
>>>        u64 mask = gfs_info->sectorsize - 1;
>>> -     u32 max_inline_size = min_t(u32, mask,
>>> +     u32 max_inline_size = min_t(u32, gfs_info->sectorsize,
>>>                                BTRFS_MAX_INLINE_DATA_SIZE(gfs_info));
>>>        u8 compression;
>>>        int extent_type;
>>
> 

Re: [PATCH v2 5/8] btrfs-progs: print encryptin type field of file extents

[Qu Wenruo]

在 2026/7/2 01:29, Daniel Vacek 写道:
> On Fri, 26 Jun 2026 at 01:50, Qu Wenruo <wqu@suse.com> wrote:
>> 在 2026/6/25 02:21, Daniel Vacek 写道:
>>> From: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
>>>
>>> Encrypted file extents now have the 'encryption' field set to an
>>> encryption type.  Let's print it.
>>>
>>> Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
>>> Signed-off-by: Daniel Vacek <neelx@suse.com>
>>> ---
>>>    check/main.c               | 1 -
>>>    kernel-shared/print-tree.c | 2 ++
>>>    2 files changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/check/main.c b/check/main.c
>>> index dedb4db4..a32247b3 100644
>>> --- a/check/main.c
>>> +++ b/check/main.c
>>> @@ -1778,7 +1778,6 @@ static int process_file_extent(struct btrfs_root *root,
>>>                        rec->errors |= I_ERR_BAD_FILE_EXTENT;
>>>                if (extent_type == BTRFS_FILE_EXTENT_PREALLOC &&
>>>                    (btrfs_file_extent_compression(eb, fi) ||
>>> -                  btrfs_file_extent_encryption(eb, fi) ||
>>
>> May I ask why preallocated file extent would have encryption value set?
>>
>> My common sense says that encryption policy should only be set for
>> regular file extents.
> 
> There's nothing wrong with pre-allocating encrypted files. Unlike
> compression, the exact size is known beforehand.

IN that case, does it mean even a hole will have encryption value set?

This looks weird. Is there any special reason for setting encryption 
value for hole/preallocated range?

Can't we only set the encryption value only for regular, 
non-preallocated extents?

Thanks,
Qu

> 
> Simillar to NOCOW, the encrypted data will be stored with the next write.
> 
> --nX
> 
>> Thanks,
>> Qu
>>
>>>                     btrfs_file_extent_other_encoding(eb, fi)))
>>>                        rec->errors |= I_ERR_BAD_FILE_EXTENT;
>>>                if (compression && rec->nodatasum)
>>> diff --git a/kernel-shared/print-tree.c b/kernel-shared/print-tree.c
>>> index 0afa3696..159f0825 100644
>>> --- a/kernel-shared/print-tree.c
>>> +++ b/kernel-shared/print-tree.c
>>> @@ -471,6 +471,8 @@ static void print_file_extent_item(struct extent_buffer *eb,
>>>        printf("\t\textent compression %hhu (%s)\n",
>>>                        btrfs_file_extent_compression(eb, fi),
>>>                        compress_str);
>>> +     printf("\t\textent encryption %hhu\n",
>>> +                     btrfs_file_extent_encryption(eb, fi));
>>>    }
>>>
>>>    /* Caller should ensure sizeof(*ret) >= 16("DATA|TREE_BLOCK") */
>>
> 

Re: [PATCH v2 1/8] btrfs-progs: check: fix max inline extent size

[Daniel Vacek]

On Thu, 2 Jul 2026 at 00:22, Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
> 在 2026/7/2 01:17, Daniel Vacek 写道:
> > On Fri, 26 Jun 2026 at 01:41, Qu Wenruo <wqu@suse.com> wrote:
> >> 在 2026/6/25 02:21, Daniel Vacek 写道:
> >>> From: Josef Bacik <josef@toxicpanda.com>
> >>>
> >>> Fscrypt will use our entire inline extent range for symlinks, which
> >>> uncovered a bug in btrfs check where we set the maximum inline extent
> >>> size to
> >>>
> >>> min(sectorsize - 1, BTRFS_MAX_INLINE_DATA_SIZE)
> >>>
> >>> which isn't correct, we have always allowed sectorsize sized inline
> >>> extents, so fix check to use the correct maximum inline extent size.
> >>
> >> No, we only allow sector sized inline extent when it is compressed.
> >> The de-compressed size can be sector sized, but the compressed size
> >> still can not reach sector size.
> >>
> >> So this doesn't seems correct to me.
> >
> > With encryption it's the other way around. Even shorter data (symlink
> > path) is always padded to multiple of the cipher block size (16 bytes
> > with AES). Inlining a full sector size is perfectly valid. The dump
> > from my test looks like this:
> >
> > ~~~
> >      item 45 key (290 DIR_ITEM 3363472967) itemoff 11425 itemsize 62
> >          location key (300 INODE_ITEM 0) type SYMLINK
> >          transid 14 data_len 0 name_len 32
> >          name: \243\365@;\312\321\240\367\377\234_{\245\vW\
> > \035\rS\222ryN\323\031g\243\nt3\321+
> >
> >      item 58 key (290 DIR_INDEX 11) itemoff 10077 itemsize 62
> >          location key (300 INODE_ITEM 0) type SYMLINK
> >          transid 14 data_len 0 name_len 32
> >          name: \243\365@;\312\321\240\367\377\234_{\245\vW\
> > \035\rS\222ryN\323\031g\243\nt3\321+
> >
> >      item 86 key (300 INODE_ITEM 0) itemoff 7197 itemsize 160
> >          generation 14 transid 14 size 4096 nbytes 4096
> >          block group 0 mode 120777 links 1 uid 0 gid 0 rdev 0
> >          sequence 1829 flags 0x1000(ENCRYPT)
> >          atime 1782916271.8000000 (2026-07-01 16:31:11)
> >          ctime 1782916271.8000000 (2026-07-01 16:31:11)
> >          mtime 1782916271.8000000 (2026-07-01 16:31:11)
> >          otime 1782916271.8000000 (2026-07-01 16:31:11)
> >      item 87 key (300 INODE_REF 290) itemoff 7155 itemsize 42
> >          index 11 namelen 32 name:
> > \243\365@;\312\321\240\367\377\234_{\245\vW\
> > \035\rS\222ryN\323\031g\243\nt3\321+
> >      item 88 key (300 FSCRYPT_INODE_CTX 0) itemoff 7115 itemsize 40
> >          value: 02010403000000005f0642cd89f66ce3ed930fe3ac518b7381bcd7600f7ae1f08195bda44461ed5d
> >      item 89 key (300 EXTENT_DATA 0) itemoff 2998 itemsize 4117
> >          generation 14 type 0 (inline)
> >          inline extent data size 4096 ram_bytes 4096 compression 0 (none)
> > ~~~
> >
> > Perhaps this would better be folded into patch 7?
> >
> > Or do you rather mean special-casing for compression (with the limits
> > as you mentioned) and encryption (with full sector size allowed)?
>
> In that case, I'd prefer the limit to be only loosen for encryption.
>
> So we won't have unexpected non-encrypted inlined extents to reach the
> limit.
>
> BTW, it would be great if the progs dump-tree also prints encryption
> value for the inlined extent.

Makes sense. I'll drop this one and rework patch 7 then. Thanks.

--nX

> Thanks,
> Qu
>
> >
> > --nX
> >
> >>> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
> >>> Signed-off-by: Daniel Vacek <neelx@suse.com>
> >>> ---
> >>>    check/main.c | 2 +-
> >>>    1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/check/main.c b/check/main.c
> >>> index 5e29e2c5..dedb4db4 100644
> >>> --- a/check/main.c
> >>> +++ b/check/main.c
> >>> @@ -1720,7 +1720,7 @@ static int process_file_extent(struct btrfs_root *root,
> >>>        u64 disk_bytenr = 0;
> >>>        u64 extent_offset = 0;
> >>>        u64 mask = gfs_info->sectorsize - 1;
> >>> -     u32 max_inline_size = min_t(u32, mask,
> >>> +     u32 max_inline_size = min_t(u32, gfs_info->sectorsize,
> >>>                                BTRFS_MAX_INLINE_DATA_SIZE(gfs_info));
> >>>        u8 compression;
> >>>        int extent_type;
> >>
> >
>

Re: [PATCH v2 5/8] btrfs-progs: print encryptin type field of file extents

[Daniel Vacek]

On Thu, 2 Jul 2026 at 00:26, Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
> 在 2026/7/2 01:29, Daniel Vacek 写道:
> > On Fri, 26 Jun 2026 at 01:50, Qu Wenruo <wqu@suse.com> wrote:
> >> 在 2026/6/25 02:21, Daniel Vacek 写道:
> >>> From: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
> >>>
> >>> Encrypted file extents now have the 'encryption' field set to an
> >>> encryption type.  Let's print it.
> >>>
> >>> Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
> >>> Signed-off-by: Daniel Vacek <neelx@suse.com>
> >>> ---
> >>>    check/main.c               | 1 -
> >>>    kernel-shared/print-tree.c | 2 ++
> >>>    2 files changed, 2 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/check/main.c b/check/main.c
> >>> index dedb4db4..a32247b3 100644
> >>> --- a/check/main.c
> >>> +++ b/check/main.c
> >>> @@ -1778,7 +1778,6 @@ static int process_file_extent(struct btrfs_root *root,
> >>>                        rec->errors |= I_ERR_BAD_FILE_EXTENT;
> >>>                if (extent_type == BTRFS_FILE_EXTENT_PREALLOC &&
> >>>                    (btrfs_file_extent_compression(eb, fi) ||
> >>> -                  btrfs_file_extent_encryption(eb, fi) ||
> >>
> >> May I ask why preallocated file extent would have encryption value set?
> >>
> >> My common sense says that encryption policy should only be set for
> >> regular file extents.
> >
> > There's nothing wrong with pre-allocating encrypted files. Unlike
> > compression, the exact size is known beforehand.
>
> IN that case, does it mean even a hole will have encryption value set?
>
> This looks weird. Is there any special reason for setting encryption
> value for hole/preallocated range?
>
> Can't we only set the encryption value only for regular,
> non-preallocated extents?

What's so weird about it? Since the inode is encrypted, related parts are too.

--nX

> Thanks,
> Qu
>
> >
> > Simillar to NOCOW, the encrypted data will be stored with the next write.
> >
> > --nX
> >
> >> Thanks,
> >> Qu
> >>
> >>>                     btrfs_file_extent_other_encoding(eb, fi)))
> >>>                        rec->errors |= I_ERR_BAD_FILE_EXTENT;
> >>>                if (compression && rec->nodatasum)
> >>> diff --git a/kernel-shared/print-tree.c b/kernel-shared/print-tree.c
> >>> index 0afa3696..159f0825 100644
> >>> --- a/kernel-shared/print-tree.c
> >>> +++ b/kernel-shared/print-tree.c
> >>> @@ -471,6 +471,8 @@ static void print_file_extent_item(struct extent_buffer *eb,
> >>>        printf("\t\textent compression %hhu (%s)\n",
> >>>                        btrfs_file_extent_compression(eb, fi),
> >>>                        compress_str);
> >>> +     printf("\t\textent encryption %hhu\n",
> >>> +                     btrfs_file_extent_encryption(eb, fi));
> >>>    }
> >>>
> >>>    /* Caller should ensure sizeof(*ret) >= 16("DATA|TREE_BLOCK") */
> >>
> >
>

Re: [PATCH v2 5/8] btrfs-progs: print encryptin type field of file extents

[Qu Wenruo]

在 2026/7/2 15:10, Daniel Vacek 写道:
> On Thu, 2 Jul 2026 at 00:26, Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>> 在 2026/7/2 01:29, Daniel Vacek 写道:
>>> On Fri, 26 Jun 2026 at 01:50, Qu Wenruo <wqu@suse.com> wrote:
>>>> 在 2026/6/25 02:21, Daniel Vacek 写道:
>>>>> From: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
>>>>>
>>>>> Encrypted file extents now have the 'encryption' field set to an
>>>>> encryption type.  Let's print it.
>>>>>
>>>>> Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
>>>>> Signed-off-by: Daniel Vacek <neelx@suse.com>
>>>>> ---
>>>>>     check/main.c               | 1 -
>>>>>     kernel-shared/print-tree.c | 2 ++
>>>>>     2 files changed, 2 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/check/main.c b/check/main.c
>>>>> index dedb4db4..a32247b3 100644
>>>>> --- a/check/main.c
>>>>> +++ b/check/main.c
>>>>> @@ -1778,7 +1778,6 @@ static int process_file_extent(struct btrfs_root *root,
>>>>>                         rec->errors |= I_ERR_BAD_FILE_EXTENT;
>>>>>                 if (extent_type == BTRFS_FILE_EXTENT_PREALLOC &&
>>>>>                     (btrfs_file_extent_compression(eb, fi) ||
>>>>> -                  btrfs_file_extent_encryption(eb, fi) ||
>>>>
>>>> May I ask why preallocated file extent would have encryption value set?
>>>>
>>>> My common sense says that encryption policy should only be set for
>>>> regular file extents.
>>>
>>> There's nothing wrong with pre-allocating encrypted files. Unlike
>>> compression, the exact size is known beforehand.
>>
>> IN that case, does it mean even a hole will have encryption value set?
>>
>> This looks weird. Is there any special reason for setting encryption
>> value for hole/preallocated range?
>>
>> Can't we only set the encryption value only for regular,
>> non-preallocated extents?
> 
> What's so weird about it? Since the inode is encrypted, related parts are too.

Inodes can have PREALLOC flags, but the file extents are not all 
preallocated.

Inode can also have COMPRESS flag, but the file extents are not all 
compressed either.

Inode flags are independent from file extent flags from the very beginning.

> 
> --nX
> 
>> Thanks,
>> Qu
>>
>>>
>>> Simillar to NOCOW, the encrypted data will be stored with the next write.
>>>
>>> --nX
>>>
>>>> Thanks,
>>>> Qu
>>>>
>>>>>                      btrfs_file_extent_other_encoding(eb, fi)))
>>>>>                         rec->errors |= I_ERR_BAD_FILE_EXTENT;
>>>>>                 if (compression && rec->nodatasum)
>>>>> diff --git a/kernel-shared/print-tree.c b/kernel-shared/print-tree.c
>>>>> index 0afa3696..159f0825 100644
>>>>> --- a/kernel-shared/print-tree.c
>>>>> +++ b/kernel-shared/print-tree.c
>>>>> @@ -471,6 +471,8 @@ static void print_file_extent_item(struct extent_buffer *eb,
>>>>>         printf("\t\textent compression %hhu (%s)\n",
>>>>>                         btrfs_file_extent_compression(eb, fi),
>>>>>                         compress_str);
>>>>> +     printf("\t\textent encryption %hhu\n",
>>>>> +                     btrfs_file_extent_encryption(eb, fi));
>>>>>     }
>>>>>
>>>>>     /* Caller should ensure sizeof(*ret) >= 16("DATA|TREE_BLOCK") */
>>>>
>>>
>>

Re: [PATCH v2 5/8] btrfs-progs: print encryptin type field of file extents

[Daniel Vacek]

On Thu, 2 Jul 2026 at 08:19, Qu Wenruo <wqu@suse.com> wrote:
> 在 2026/7/2 15:10, Daniel Vacek 写道:
> > On Thu, 2 Jul 2026 at 00:26, Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
> >> 在 2026/7/2 01:29, Daniel Vacek 写道:
> >>> On Fri, 26 Jun 2026 at 01:50, Qu Wenruo <wqu@suse.com> wrote:
> >>>> 在 2026/6/25 02:21, Daniel Vacek 写道:
> >>>>> From: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
> >>>>>
> >>>>> Encrypted file extents now have the 'encryption' field set to an
> >>>>> encryption type.  Let's print it.
> >>>>>
> >>>>> Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
> >>>>> Signed-off-by: Daniel Vacek <neelx@suse.com>
> >>>>> ---
> >>>>>     check/main.c               | 1 -
> >>>>>     kernel-shared/print-tree.c | 2 ++
> >>>>>     2 files changed, 2 insertions(+), 1 deletion(-)
> >>>>>
> >>>>> diff --git a/check/main.c b/check/main.c
> >>>>> index dedb4db4..a32247b3 100644
> >>>>> --- a/check/main.c
> >>>>> +++ b/check/main.c
> >>>>> @@ -1778,7 +1778,6 @@ static int process_file_extent(struct btrfs_root *root,
> >>>>>                         rec->errors |= I_ERR_BAD_FILE_EXTENT;
> >>>>>                 if (extent_type == BTRFS_FILE_EXTENT_PREALLOC &&
> >>>>>                     (btrfs_file_extent_compression(eb, fi) ||
> >>>>> -                  btrfs_file_extent_encryption(eb, fi) ||
> >>>>
> >>>> May I ask why preallocated file extent would have encryption value set?
> >>>>
> >>>> My common sense says that encryption policy should only be set for
> >>>> regular file extents.
> >>>
> >>> There's nothing wrong with pre-allocating encrypted files. Unlike
> >>> compression, the exact size is known beforehand.
> >>
> >> IN that case, does it mean even a hole will have encryption value set?
> >>
> >> This looks weird. Is there any special reason for setting encryption
> >> value for hole/preallocated range?
> >>
> >> Can't we only set the encryption value only for regular,
> >> non-preallocated extents?
> >
> > What's so weird about it? Since the inode is encrypted, related parts are too.
>
> Inodes can have PREALLOC flags, but the file extents are not all
> preallocated.
>
> Inode can also have COMPRESS flag, but the file extents are not all
> compressed either.
>
> Inode flags are independent from file extent flags from the very beginning.

Encryption is not compression. I'm not sure it makes sense to compare
them this way.
We don't want to have some parts of a file encrypted and some plain.
A file is either fully encrypted or not at all.
In that sense we are being a bit more strict than what you may be used to. See?

--nX

> >
> > --nX
> >
> >> Thanks,
> >> Qu
> >>
> >>>
> >>> Simillar to NOCOW, the encrypted data will be stored with the next write.
> >>>
> >>> --nX
> >>>
> >>>> Thanks,
> >>>> Qu
> >>>>
> >>>>>                      btrfs_file_extent_other_encoding(eb, fi)))
> >>>>>                         rec->errors |= I_ERR_BAD_FILE_EXTENT;
> >>>>>                 if (compression && rec->nodatasum)
> >>>>> diff --git a/kernel-shared/print-tree.c b/kernel-shared/print-tree.c
> >>>>> index 0afa3696..159f0825 100644
> >>>>> --- a/kernel-shared/print-tree.c
> >>>>> +++ b/kernel-shared/print-tree.c
> >>>>> @@ -471,6 +471,8 @@ static void print_file_extent_item(struct extent_buffer *eb,
> >>>>>         printf("\t\textent compression %hhu (%s)\n",
> >>>>>                         btrfs_file_extent_compression(eb, fi),
> >>>>>                         compress_str);
> >>>>> +     printf("\t\textent encryption %hhu\n",
> >>>>> +                     btrfs_file_extent_encryption(eb, fi));
> >>>>>     }
> >>>>>
> >>>>>     /* Caller should ensure sizeof(*ret) >= 16("DATA|TREE_BLOCK") */
> >>>>
> >>>
> >>
>

Re: [PATCH v2 5/8] btrfs-progs: print encryptin type field of file extents

[Qu Wenruo]

在 2026/7/2 16:18, Daniel Vacek 写道:
> On Thu, 2 Jul 2026 at 08:19, Qu Wenruo <wqu@suse.com> wrote:
>> 在 2026/7/2 15:10, Daniel Vacek 写道:
>>> On Thu, 2 Jul 2026 at 00:26, Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>>>> 在 2026/7/2 01:29, Daniel Vacek 写道:
>>>>> On Fri, 26 Jun 2026 at 01:50, Qu Wenruo <wqu@suse.com> wrote:
>>>>>> 在 2026/6/25 02:21, Daniel Vacek 写道:
>>>>>>> From: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
>>>>>>>
>>>>>>> Encrypted file extents now have the 'encryption' field set to an
>>>>>>> encryption type.  Let's print it.
>>>>>>>
>>>>>>> Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
>>>>>>> Signed-off-by: Daniel Vacek <neelx@suse.com>
>>>>>>> ---
>>>>>>>      check/main.c               | 1 -
>>>>>>>      kernel-shared/print-tree.c | 2 ++
>>>>>>>      2 files changed, 2 insertions(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/check/main.c b/check/main.c
>>>>>>> index dedb4db4..a32247b3 100644
>>>>>>> --- a/check/main.c
>>>>>>> +++ b/check/main.c
>>>>>>> @@ -1778,7 +1778,6 @@ static int process_file_extent(struct btrfs_root *root,
>>>>>>>                          rec->errors |= I_ERR_BAD_FILE_EXTENT;
>>>>>>>                  if (extent_type == BTRFS_FILE_EXTENT_PREALLOC &&
>>>>>>>                      (btrfs_file_extent_compression(eb, fi) ||
>>>>>>> -                  btrfs_file_extent_encryption(eb, fi) ||
>>>>>>
>>>>>> May I ask why preallocated file extent would have encryption value set?
>>>>>>
>>>>>> My common sense says that encryption policy should only be set for
>>>>>> regular file extents.
>>>>>
>>>>> There's nothing wrong with pre-allocating encrypted files. Unlike
>>>>> compression, the exact size is known beforehand.
>>>>
>>>> IN that case, does it mean even a hole will have encryption value set?
>>>>
>>>> This looks weird. Is there any special reason for setting encryption
>>>> value for hole/preallocated range?
>>>>
>>>> Can't we only set the encryption value only for regular,
>>>> non-preallocated extents?
>>>
>>> What's so weird about it? Since the inode is encrypted, related parts are too.
>>
>> Inodes can have PREALLOC flags, but the file extents are not all
>> preallocated.
>>
>> Inode can also have COMPRESS flag, but the file extents are not all
>> compressed either.
>>
>> Inode flags are independent from file extent flags from the very beginning.
> 
> Encryption is not compression. I'm not sure it makes sense to compare
> them this way.
> We don't want to have some parts of a file encrypted and some plain.
> A file is either fully encrypted or not at all.

Then you're only cheating yourself.

A simple tree dump can always show which range is hole and which is 
preallocated.

> In that sense we are being a bit more strict than what you may be used to. See?
> 
> --nX
> 
>>>
>>> --nX
>>>
>>>> Thanks,
>>>> Qu
>>>>
>>>>>
>>>>> Simillar to NOCOW, the encrypted data will be stored with the next write.
>>>>>
>>>>> --nX
>>>>>
>>>>>> Thanks,
>>>>>> Qu
>>>>>>
>>>>>>>                       btrfs_file_extent_other_encoding(eb, fi)))
>>>>>>>                          rec->errors |= I_ERR_BAD_FILE_EXTENT;
>>>>>>>                  if (compression && rec->nodatasum)
>>>>>>> diff --git a/kernel-shared/print-tree.c b/kernel-shared/print-tree.c
>>>>>>> index 0afa3696..159f0825 100644
>>>>>>> --- a/kernel-shared/print-tree.c
>>>>>>> +++ b/kernel-shared/print-tree.c
>>>>>>> @@ -471,6 +471,8 @@ static void print_file_extent_item(struct extent_buffer *eb,
>>>>>>>          printf("\t\textent compression %hhu (%s)\n",
>>>>>>>                          btrfs_file_extent_compression(eb, fi),
>>>>>>>                          compress_str);
>>>>>>> +     printf("\t\textent encryption %hhu\n",
>>>>>>> +                     btrfs_file_extent_encryption(eb, fi));
>>>>>>>      }
>>>>>>>
>>>>>>>      /* Caller should ensure sizeof(*ret) >= 16("DATA|TREE_BLOCK") */
>>>>>>
>>>>>
>>>>
>>
> 

Re: [PATCH v2 5/8] btrfs-progs: print encryptin type field of file extents

[Daniel Vacek]

On Thu, 2 Jul 2026 at 08:56, Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
> 在 2026/7/2 16:18, Daniel Vacek 写道:
> > On Thu, 2 Jul 2026 at 08:19, Qu Wenruo <wqu@suse.com> wrote:
> >> 在 2026/7/2 15:10, Daniel Vacek 写道:
> >>> On Thu, 2 Jul 2026 at 00:26, Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
> >>>> 在 2026/7/2 01:29, Daniel Vacek 写道:
> >>>>> On Fri, 26 Jun 2026 at 01:50, Qu Wenruo <wqu@suse.com> wrote:
> >>>>>> 在 2026/6/25 02:21, Daniel Vacek 写道:
> >>>>>>> From: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
> >>>>>>>
> >>>>>>> Encrypted file extents now have the 'encryption' field set to an
> >>>>>>> encryption type.  Let's print it.
> >>>>>>>
> >>>>>>> Signed-off-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
> >>>>>>> Signed-off-by: Daniel Vacek <neelx@suse.com>
> >>>>>>> ---
> >>>>>>>      check/main.c               | 1 -
> >>>>>>>      kernel-shared/print-tree.c | 2 ++
> >>>>>>>      2 files changed, 2 insertions(+), 1 deletion(-)
> >>>>>>>
> >>>>>>> diff --git a/check/main.c b/check/main.c
> >>>>>>> index dedb4db4..a32247b3 100644
> >>>>>>> --- a/check/main.c
> >>>>>>> +++ b/check/main.c
> >>>>>>> @@ -1778,7 +1778,6 @@ static int process_file_extent(struct btrfs_root *root,
> >>>>>>>                          rec->errors |= I_ERR_BAD_FILE_EXTENT;
> >>>>>>>                  if (extent_type == BTRFS_FILE_EXTENT_PREALLOC &&
> >>>>>>>                      (btrfs_file_extent_compression(eb, fi) ||
> >>>>>>> -                  btrfs_file_extent_encryption(eb, fi) ||
> >>>>>>
> >>>>>> May I ask why preallocated file extent would have encryption value set?
> >>>>>>
> >>>>>> My common sense says that encryption policy should only be set for
> >>>>>> regular file extents.
> >>>>>
> >>>>> There's nothing wrong with pre-allocating encrypted files. Unlike
> >>>>> compression, the exact size is known beforehand.
> >>>>
> >>>> IN that case, does it mean even a hole will have encryption value set?
> >>>>
> >>>> This looks weird. Is there any special reason for setting encryption
> >>>> value for hole/preallocated range?
> >>>>
> >>>> Can't we only set the encryption value only for regular,
> >>>> non-preallocated extents?
> >>>
> >>> What's so weird about it? Since the inode is encrypted, related parts are too.
> >>
> >> Inodes can have PREALLOC flags, but the file extents are not all
> >> preallocated.
> >>
> >> Inode can also have COMPRESS flag, but the file extents are not all
> >> compressed either.
> >>
> >> Inode flags are independent from file extent flags from the very beginning.
> >
> > Encryption is not compression. I'm not sure it makes sense to compare
> > them this way.
> > We don't want to have some parts of a file encrypted and some plain.
> > A file is either fully encrypted or not at all.
>
> Then you're only cheating yourself.
>
> A simple tree dump can always show which range is hole and which is
> preallocated.

Yeah, that's true. I'm curious how other FSes handle this. Let me see.
Or do you know from the top of your head?

--nX

> > In that sense we are being a bit more strict than what you may be used to. See?
> >
> > --nX
> >
> >>>
> >>> --nX
> >>>
> >>>> Thanks,
> >>>> Qu
> >>>>
> >>>>>
> >>>>> Simillar to NOCOW, the encrypted data will be stored with the next write.
> >>>>>
> >>>>> --nX
> >>>>>
> >>>>>> Thanks,
> >>>>>> Qu
> >>>>>>
> >>>>>>>                       btrfs_file_extent_other_encoding(eb, fi)))
> >>>>>>>                          rec->errors |= I_ERR_BAD_FILE_EXTENT;
> >>>>>>>                  if (compression && rec->nodatasum)
> >>>>>>> diff --git a/kernel-shared/print-tree.c b/kernel-shared/print-tree.c
> >>>>>>> index 0afa3696..159f0825 100644
> >>>>>>> --- a/kernel-shared/print-tree.c
> >>>>>>> +++ b/kernel-shared/print-tree.c
> >>>>>>> @@ -471,6 +471,8 @@ static void print_file_extent_item(struct extent_buffer *eb,
> >>>>>>>          printf("\t\textent compression %hhu (%s)\n",
> >>>>>>>                          btrfs_file_extent_compression(eb, fi),
> >>>>>>>                          compress_str);
> >>>>>>> +     printf("\t\textent encryption %hhu\n",
> >>>>>>> +                     btrfs_file_extent_encryption(eb, fi));
> >>>>>>>      }
> >>>>>>>
> >>>>>>>      /* Caller should ensure sizeof(*ret) >= 16("DATA|TREE_BLOCK") */
> >>>>>>
> >>>>>
> >>>>
> >>
> >
>
>

Re: [PATCH v2 5/8] btrfs-progs: print encryptin type field of file extents

[Qu Wenruo]

在 2026/7/2 16:35, Daniel Vacek 写道:
[...]
>>
>> A simple tree dump can always show which range is hole and which is
>> preallocated.
> 
> Yeah, that's true. I'm curious how other FSes handle this. Let me see.
> Or do you know from the top of your head?

Sorry, not familiar with other fscrypt implementation at all.
You may want to try to experiment on ext4 to see how it's implemented.

I guess they do nothing special and just expose hole/prealloc info.

As the other path would be always filling hole with zero filled regular 
extents (before encryption), and disable preallocation completely.
That looks over-killed and may take a lot of extra space.

Re: [PATCH v2 5/8] btrfs-progs: print encryptin type field of file extents

[Daniel Vacek]

On Thu, 2 Jul 2026 at 09:11, Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
> 在 2026/7/2 16:35, Daniel Vacek 写道:
> [...]
> >>
> >> A simple tree dump can always show which range is hole and which is
> >> preallocated.
> >
> > Yeah, that's true. I'm curious how other FSes handle this. Let me see.
> > Or do you know from the top of your head?
>
> Sorry, not familiar with other fscrypt implementation at all.
> You may want to try to experiment on ext4 to see how it's implemented.
>
> I guess they do nothing special and just expose hole/prealloc info.
>
> As the other path would be always filling hole with zero filled regular
> extents (before encryption), and disable preallocation completely.
> That looks over-killed and may take a lot of extra space.

Well, rather filling the prealloc with the same zero-filled extent I guess.

--nX