On Thu, 2 Jul 2026 at 08:56, Qu Wenruo <[email protected]> wrote:
> 在 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.
Yeah, that's true. I'm curious how other FSes handle this. Let me see.
Or do you know from the top of your head?
--nX
> > 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") */
> >>>>>>
> >>>>>
> >>>>
> >>
> >
>
>
