| Message ID | 07579fc7e3a960384f9e4e455c11c3407f68cab1.1705135055.git.wqu@suse.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | btrfs-progs: allow tree-checker to be triggered more frequently for btrfs-convert | expand |
diff --git a/kernel-shared/extent_io.c b/kernel-shared/extent_io.c index ee19430daa12..ce5e4ffb7a59 100644 --- a/kernel-shared/extent_io.c +++ b/kernel-shared/extent_io.c @@ -43,7 +43,10 @@ static void free_extent_buffer_final(struct extent_buffer *eb); void extent_buffer_init_cache(struct btrfs_fs_info *fs_info) { - fs_info->max_cache_size = total_memory() / 4; + u64 max_cache_size = total_memory() / 4; + + get_env_u64("BTRFS_PROGS_DEBUG_METADATA_CACHE_SIZE", &max_cache_size); + fs_info->max_cache_size = max_cache_size; fs_info->cache_size = 0; INIT_LIST_HEAD(&fs_info->lru); }
Since we got a recent bug report about tree-checker triggered for large fs conversion, we need a properly way to trigger the problem for test case purpose. To trigger that bug, we need to meet several conditions: - We need to read some tree blocks which has half-backed inodes - We need a large enough enough fs to generate more tree blocks than our cache. For our existing test cases, firstly the fs is not that large, thus we may even go just one transaction to generate all the inodes. Secondly we have a global cache for tree blocks, which means a lot of written tree blocks are still in the cache, thus won't trigger tree-checker. To make the problem much easier for our existing test case to expose, this patch would introduce a debug environment variable: BTRFS_PROGS_DEBUG_METADATA_CACHE_SIZE. This variable allows us to finetune the cache size, so that we can reduce the metadata cache size and trigger more read thus more tree-checker checks to shake out more bugs. Signed-off-by: Qu Wenruo <wqu@suse.com> --- kernel-shared/extent_io.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)