mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: Daniel Vacek <neelx@suse.com>, Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: David Sterba <dsterba@suse.com>,
	linux-fscrypt@vger.kernel.org, linux-btrfs@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
Subject: Re: [PATCH v2 5/8] btrfs-progs: print encryptin type field of file extents
Date: Thu, 2 Jul 2026 15:49:46 +0930	[thread overview]
Message-ID: <5a8f027b-420e-41be-b852-a27fb084c32f@suse.com> (raw)
In-Reply-To: <CAPjX3Fe0xAYM16yrUyPEWChBrS0ow0HCr_u8S2jR+XCnZzxC2Q@mail.gmail.com>



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


  reply	other threads:[~2026-07-02  6:19 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-24 16:51 [PATCH v2 0/8] btrfs-progs: fscrypt updates Daniel Vacek
2026-06-24 16:51 ` [PATCH v2 1/8] btrfs-progs: check: fix max inline extent size Daniel Vacek
2026-06-25 23:40   ` Qu Wenruo
2026-07-01 15:47     ` Daniel Vacek
2026-07-01 22:22       ` Qu Wenruo
2026-07-02  5:34         ` Daniel Vacek
2026-06-24 16:51 ` [PATCH v2 2/8] btrfs-progs: add new FEATURE_INCOMPAT_ENCRYPT flag Daniel Vacek
2026-06-24 16:51 ` [PATCH v2 3/8] btrfs-progs: start tracking extent encryption context info Daniel Vacek
2026-06-24 16:51 ` [PATCH v2 4/8] btrfs-progs: add inode encryption contexts Daniel Vacek
2026-06-24 16:51 ` [PATCH v2 5/8] btrfs-progs: print encryptin type field of file extents Daniel Vacek
2026-06-25 23:50   ` Qu Wenruo
2026-07-01 15:59     ` Daniel Vacek
2026-07-01 22:26       ` Qu Wenruo
2026-07-02  5:40         ` Daniel Vacek
2026-07-02  6:19           ` Qu Wenruo [this message]
2026-07-02  6:48             ` Daniel Vacek
2026-07-02  6:56               ` Qu Wenruo
2026-07-02  7:05                 ` Daniel Vacek
2026-07-02  7:11                   ` Qu Wenruo
2026-07-02  7:18                     ` Daniel Vacek
2026-06-24 16:51 ` [PATCH v2 6/8] btrfs-progs: handle fscrypt context items Daniel Vacek
2026-06-24 16:51 ` [PATCH v2 7/8] btrfs-progs: check: update inline extent length checking Daniel Vacek
2026-06-24 16:51 ` [PATCH v2 8/8] btrfs-progs: recognize ENCRYPT inode item flag Daniel Vacek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5a8f027b-420e-41be-b852-a27fb084c32f@suse.com \
    --to=wqu@suse.com \
    --cc=dsterba@suse.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neelx@suse.com \
    --cc=quwenruo.btrfs@gmx.com \
    --cc=sweettea-kernel@dorminy.me \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®