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

在 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") */
>>>>>>
>>>>>
>>>>
>>
>