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