在 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;
