On Thu, 2 Jul 2026 at 00:22, Qu Wenruo <[email protected]> wrote: > 在 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.
Makes sense. I'll drop this one and rework patch 7 then. Thanks. --nX > 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; > >> > > >
