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@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.

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