linux-ext4 - Re: ext4lazyinit reads HDD data on mount since 5.13

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 9 Aug 2021 09:18:47 -0700
From:   harshad shirwadkar <harshadshirwadkar@...il.com>
To:     ValdikSS <iam@...dikss.org.ru>
Cc:     "Theodore Ts'o" <tytso@....edu>,
        Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: ext4lazyinit reads HDD data on mount since 5.13

On Mon, Aug 9, 2021 at 2:51 AM ValdikSS <iam@...dikss.org.ru> 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