On Mon, Aug 9, 2021 at 2:51 AM ValdikSS <iam@xxxxxxxxxxxxxxx> wrote: > > On 09.08.2021 04:51, Theodore Ts'o wrote: > > 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
