| Message ID | 20180302052254.7059-6-wqu@suse.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 2018/03/02 14:22, Qu Wenruo wrote: > Btrfs shows max_inline option into kernel message, but for > max_inline=4096, btrfs won't really inline 4096 bytes inline data if > it's not compressed. Hello, I have a question. man mount(8) says: max_inline=bytes Specify the maximum amount of space, in bytes, that can be inlined in a metadata B-tree leaf. The value is specified in bytes, optionally with a K, M, or G suffix, case insensitive. In practice, this value is limited by the root sector size, with some space unavailable due to leaf headers. For a 4k sectorsize, max inline data is ~3900 bytes. So, is the size of 4k-(size of leaf header) actually the maximum value of max_inline instead of 4095 for 4k sectorsize? Thanks, -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2.03.2018 10:21, Misono, Tomohiro wrote: > On 2018/03/02 14:22, Qu Wenruo wrote: >> Btrfs shows max_inline option into kernel message, but for >> max_inline=4096, btrfs won't really inline 4096 bytes inline data if >> it's not compressed. > > Hello, > I have a question. > > man mount(8) says: > max_inline=bytes > Specify the maximum amount of space, in bytes, that can be > inlined in a metadata B-tree leaf. The value is specified in > bytes, optionally with a K, M, or G suffix, case insensitive. > In practice, this value is limited by the root sector size, > with some space unavailable due to leaf headers. For a 4k > sectorsize, max inline data is ~3900 bytes. > > So, is the size of 4k-(size of leaf header) actually the maximum value > of max_inline instead of 4095 for 4k sectorsize? I think the documentation is wrong. Without patch 3/5 we have the max inline data size as: BTRFS_MAX_ITEM_SIZE(info) - BTRFS_FILE_EXTENT_INLINE_DATA_START so MAX_ITEM_SIZE = nodesize - sizeof(btrfs_header) - sizeof(btrfs_item). So this gives us the data portion in the leaf. So if we substitute the raw number we get: 16k - 101 - 25 = 16258 bytes. From this number we also subtract the offset of disk_bytenr in btrfs_file_extent_item (which is 21). So we end up with MAX_INLINE_DATA_SIZE of 16258 - 21 = 16237 With Qu's patch the min_t will always be taking 4095 as the MAX_INLINE_DATA_SIZE. > > Thanks, > > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2018年03月02日 16:21, Misono, Tomohiro wrote: > On 2018/03/02 14:22, Qu Wenruo wrote: >> Btrfs shows max_inline option into kernel message, but for >> max_inline=4096, btrfs won't really inline 4096 bytes inline data if >> it's not compressed. > > Hello, > I have a question. > > man mount(8) says: > max_inline=bytes > Specify the maximum amount of space, in bytes, that can be > inlined in a metadata B-tree leaf. The value is specified in > bytes, optionally with a K, M, or G suffix, case insensitive. > In practice, this value is limited by the root sector size, > with some space unavailable due to leaf headers. For a 4k > sectorsize, max inline data is ~3900 bytes. > > So, is the size of 4k-(size of leaf header) actually the maximum value > of max_inline instead of 4095 for 4k sectorsize? Not exactly. For 4K nodesize, max_inline would be 3960 bytes. As leaf header and EXTENT_ITEM header takes extra bytes. For 16K nodesize (default), we can go up to 4095 bytes then. And that man page needs updated, as it should be 4K *nodesize*. Thanks, Qu > > Thanks, > > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
On 2.03.2018 10:34, Qu Wenruo wrote: > > > On 2018年03月02日 16:21, Misono, Tomohiro wrote: >> On 2018/03/02 14:22, Qu Wenruo wrote: >>> Btrfs shows max_inline option into kernel message, but for >>> max_inline=4096, btrfs won't really inline 4096 bytes inline data if >>> it's not compressed. >> >> Hello, >> I have a question. >> >> man mount(8) says: >> max_inline=bytes >> Specify the maximum amount of space, in bytes, that can be >> inlined in a metadata B-tree leaf. The value is specified in >> bytes, optionally with a K, M, or G suffix, case insensitive. >> In practice, this value is limited by the root sector size, >> with some space unavailable due to leaf headers. For a 4k >> sectorsize, max inline data is ~3900 bytes. >> >> So, is the size of 4k-(size of leaf header) actually the maximum value >> of max_inline instead of 4095 for 4k sectorsize? > > Not exactly. > > For 4K nodesize, max_inline would be 3960 bytes. > As leaf header and EXTENT_ITEM header takes extra bytes. > > For 16K nodesize (default), we can go up to 4095 bytes then. > > And that man page needs updated, as it should be 4K *nodesize*. Actually Qu what is preventing the btrfs_drop_extents of dropping inline extents larger than pagesize? This why you are doing this patchset, right ? > > Thanks, > Qu > >> >> Thanks, >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2018年03月02日 16:37, Nikolay Borisov wrote: > > > On 2.03.2018 10:34, Qu Wenruo wrote: >> >> >> On 2018年03月02日 16:21, Misono, Tomohiro wrote: >>> On 2018/03/02 14:22, Qu Wenruo wrote: >>>> Btrfs shows max_inline option into kernel message, but for >>>> max_inline=4096, btrfs won't really inline 4096 bytes inline data if >>>> it's not compressed. >>> >>> Hello, >>> I have a question. >>> >>> man mount(8) says: >>> max_inline=bytes >>> Specify the maximum amount of space, in bytes, that can be >>> inlined in a metadata B-tree leaf. The value is specified in >>> bytes, optionally with a K, M, or G suffix, case insensitive. >>> In practice, this value is limited by the root sector size, >>> with some space unavailable due to leaf headers. For a 4k >>> sectorsize, max inline data is ~3900 bytes. >>> >>> So, is the size of 4k-(size of leaf header) actually the maximum value >>> of max_inline instead of 4095 for 4k sectorsize? >> >> Not exactly. >> >> For 4K nodesize, max_inline would be 3960 bytes. >> As leaf header and EXTENT_ITEM header takes extra bytes. >> >> For 16K nodesize (default), we can go up to 4095 bytes then. >> >> And that man page needs updated, as it should be 4K *nodesize*. > > Actually Qu what is preventing the btrfs_drop_extents of dropping inline > extents larger than pagesize? This why you are doing this patchset, right ? In fact, current kernel code won't create any inline extent for real file to cross page boundary. So kernel itself won't try to call __btrfs_drop_extents() inside inline extent. (Although for symbol link, we can still create such large inline extent, but we won't use __btrfs_drop_extent() in this case). What I'm doing in this patchset is to fix the confusing behavior related to inline extents. From its different behavior between plain and compressed extent to larger than one page inlined extent used in symbol link. Thanks, Qu > >> >> Thanks, >> Qu >> >>> >>> Thanks, >>> >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in >>> the body of a message to majordomo@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >> > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c index 3a4dce153645..6685016bc0ec 100644 --- a/fs/btrfs/super.c +++ b/fs/btrfs/super.c @@ -618,8 +618,8 @@ int btrfs_parse_options(struct btrfs_fs_info *info, char *options, if (info->max_inline) { info->max_inline = min_t(u64, - info->max_inline, - info->sectorsize); + info->max_inline, + BTRFS_MAX_INLINE_DATA_SIZE(info)); } btrfs_info(info, "max_inline at %llu", info->max_inline);
Btrfs shows max_inline option into kernel message, but for max_inline=4096, btrfs won't really inline 4096 bytes inline data if it's not compressed. Since we have unified the behavior and now BTRFS_MAX_INLINE_DATA_SIZE() should handle most of the condition check, just limit fs_info->max_inline to BTRFS_MAX_INLINE_DATA_SIZE(), so we could have more accurate max_inline output. Signed-off-by: Qu Wenruo <wqu@suse.com> --- fs/btrfs/super.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)