Re: ext4lazyinit reads HDD data on mount since 5.13

On Mon, Aug 9, 2021 at 2:51 AM ValdikSS [off-list ref] wrote:

On 09.08.2021 04:51, Theodore Ts'o wrote:

quoted

It's a new feature which optimizes block allocations for very large
file systems.  The work being done by ext4lazyinit is to read the
block allocation bitmaps so we can cache the buddy bitmaps and how
fragmented (or not) various block groups are, which is used to
optimize the block allocator.

Thanks for the info. To revert old behavior, the filesystem should be
mounted with -o no_prefetch_block_bitmaps

Is it safe to use this option with new optimizations? Should I expect
only less optimal filesystem speed and no other issues?

It is perfectly safe to use "no_prefetch_block_bitmaps" with new
optimizations. In fact file system throughput also will NOT be
affected if you mount the file system with this option. The only
impact of mounting with this mount option would be that the file
system can potentially make sub-optimal decisions for allocation
requests in certain scenarios. For example, let's say the allocator
gets a request to allocate 10 contiguous blocks and only the last
group in the file system has 10 contiguous blocks. If you mount the
file system with "no_prefetch_block_bitmaps", Ext4 will not have
cached the last group's buddy bitmap because of which it might not
know that the last group has 10 contiguous blocks available. At this
point, Ext4 will satisfy the request for 10 blocks by allocating
fragments instead of allocating a contiguous region. This might
increase the fragmentation levels of the file system. However, note
that this is not a regression. If you were not using
"prefetch_block_bitmaps" before 5.13, then this is the allocator
behavior that you would have seen anyway. So, mounting with
"no_prefetch_block_bitmaps" in your setup, would not cause any
regressions whatsoever.

Thanks,
Harshad