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@xxxxxxxx> wrote:
> 在 2026/7/2 15:10, Daniel Vacek 写道:
> > On Thu, 2 Jul 2026 at 00:26, Qu Wenruo <quwenruo.btrfs@xxxxxxx> wrote:
> >> 在 2026/7/2 01:29, Daniel Vacek 写道:
> >>> On Fri, 26 Jun 2026 at 01:50, Qu Wenruo <wqu@xxxxxxxx> wrote:
> >>>> 在 2026/6/25 02:21, Daniel Vacek 写道:
> >>>>> From: Sweet Tea Dorminy <sweettea-kernel@xxxxxxxxxx>
> >>>>>
> >>>>> 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@xxxxxxxxxx>
> >>>>> Signed-off-by: Daniel Vacek <neelx@xxxxxxxx>
> >>>>> ---
> >>>>>     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") */
> >>>>
> >>>
> >>
>