Re: [PATCH v2 1/8] btrfs-progs: check: fix max inline extent size

在 2026/7/2 01:17, Daniel Vacek 写道:
> On Fri, 26 Jun 2026 at 01:41, Qu Wenruo <[email protected]> wrote:
>> 在 2026/6/25 02:21, Daniel Vacek 写道:
>>> From: Josef Bacik <[email protected]>
>>>
>>> Fscrypt will use our entire inline extent range for symlinks, which
>>> uncovered a bug in btrfs check where we set the maximum inline extent
>>> size to
>>>
>>> min(sectorsize - 1, BTRFS_MAX_INLINE_DATA_SIZE)
>>>
>>> which isn't correct, we have always allowed sectorsize sized inline
>>> extents, so fix check to use the correct maximum inline extent size.
>>
>> No, we only allow sector sized inline extent when it is compressed.
>> The de-compressed size can be sector sized, but the compressed size
>> still can not reach sector size.
>>
>> So this doesn't seems correct to me.
> 
> With encryption it's the other way around. Even shorter data (symlink
> path) is always padded to multiple of the cipher block size (16 bytes
> with AES). Inlining a full sector size is perfectly valid. The dump
> from my test looks like this:
> 
> ~~~
>      item 45 key (290 DIR_ITEM 3363472967) itemoff 11425 itemsize 62
>          location key (300 INODE_ITEM 0) type SYMLINK
>          transid 14 data_len 0 name_len 32
>          name: \243\365@;\312\321\240\367\377\234_{\245\vW\
> \035\rS\222ryN\323\031g\243\nt3\321+
> 
>      item 58 key (290 DIR_INDEX 11) itemoff 10077 itemsize 62
>          location key (300 INODE_ITEM 0) type SYMLINK
>          transid 14 data_len 0 name_len 32
>          name: \243\365@;\312\321\240\367\377\234_{\245\vW\
> \035\rS\222ryN\323\031g\243\nt3\321+
> 
>      item 86 key (300 INODE_ITEM 0) itemoff 7197 itemsize 160
>          generation 14 transid 14 size 4096 nbytes 4096
>          block group 0 mode 120777 links 1 uid 0 gid 0 rdev 0
>          sequence 1829 flags 0x1000(ENCRYPT)
>          atime 1782916271.8000000 (2026-07-01 16:31:11)
>          ctime 1782916271.8000000 (2026-07-01 16:31:11)
>          mtime 1782916271.8000000 (2026-07-01 16:31:11)
>          otime 1782916271.8000000 (2026-07-01 16:31:11)
>      item 87 key (300 INODE_REF 290) itemoff 7155 itemsize 42
>          index 11 namelen 32 name:
> \243\365@;\312\321\240\367\377\234_{\245\vW\
> \035\rS\222ryN\323\031g\243\nt3\321+
>      item 88 key (300 FSCRYPT_INODE_CTX 0) itemoff 7115 itemsize 40
>          value: 02010403000000005f0642cd89f66ce3ed930fe3ac518b7381bcd7600f7ae1f08195bda44461ed5d
>      item 89 key (300 EXTENT_DATA 0) itemoff 2998 itemsize 4117
>          generation 14 type 0 (inline)
>          inline extent data size 4096 ram_bytes 4096 compression 0 (none)
> ~~~
> 
> Perhaps this would better be folded into patch 7?
> 
> Or do you rather mean special-casing for compression (with the limits
> as you mentioned) and encryption (with full sector size allowed)?

In that case, I'd prefer the limit to be only loosen for encryption.

So we won't have unexpected non-encrypted inlined extents to reach the 
limit.

BTW, it would be great if the progs dump-tree also prints encryption 
value for the inlined extent.

Thanks,
Qu

> 
> --nX
> 
>>> Signed-off-by: Josef Bacik <[email protected]>
>>> Signed-off-by: Daniel Vacek <[email protected]>
>>> ---
>>>    check/main.c | 2 +-
>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/check/main.c b/check/main.c
>>> index 5e29e2c5..dedb4db4 100644
>>> --- a/check/main.c
>>> +++ b/check/main.c
>>> @@ -1720,7 +1720,7 @@ static int process_file_extent(struct btrfs_root *root,
>>>        u64 disk_bytenr = 0;
>>>        u64 extent_offset = 0;
>>>        u64 mask = gfs_info->sectorsize - 1;
>>> -     u32 max_inline_size = min_t(u32, mask,
>>> +     u32 max_inline_size = min_t(u32, gfs_info->sectorsize,
>>>                                BTRFS_MAX_INLINE_DATA_SIZE(gfs_info));
>>>        u8 compression;
>>>        int extent_type;
>>
>