在 2026/7/2 16:18, Daniel Vacek 写道:
On Thu, 2 Jul 2026 at 08:19, Qu Wenruo <[email protected]> wrote:
在 2026/7/2 15:10, Daniel Vacek 写道:
On Thu, 2 Jul 2026 at 00:26, Qu Wenruo <[email protected]> wrote:
在 2026/7/2 01:29, Daniel Vacek 写道:
On Fri, 26 Jun 2026 at 01:50, Qu Wenruo <[email protected]> wrote:
在 2026/6/25 02:21, Daniel Vacek 写道:
From: Sweet Tea Dorminy <[email protected]>
Encrypted file extents now have the 'encryption' field set to an
encryption type. Let's print it.
Signed-off-by: Sweet Tea Dorminy <[email protected]>
Signed-off-by: Daniel Vacek <[email protected]>
---
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") */
