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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <YRCKG1V/OBuble40@mit.edu>
Date:   Sun, 8 Aug 2021 21:51:23 -0400
From:   "Theodore Ts'o" <tytso@....edu>
To:     ValdikSS <iam@...dikss.org.ru>
Cc:     linux-ext4@...r.kernel.org
Subject: Re: ext4lazyinit reads HDD data on mount since 5.13

On Mon, Aug 09, 2021 at 01:13:03AM +0300, ValdikSS wrote:
> Hello,
> After updating to kernel 5.13, my ext4 partition is read for ~20 seconds
> upon mounting by ext4lazyinit. It does not write anything, only reads
> (inspected with iotop), and it does so only on mount and only for relatively
> short amount of time.
> 
> My partition is several years old and have been fully initialized long ago.
> Mounting with `init_itable=0` did not change anything: ext4lazyinit does not
> write anything to begin with.
> 
> 5.12.15 does not have such behavior. Did I miss a configuration change? Is
> that a regression or a new feature?

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.

Quoting from the commit description for 196e402adf2e:

    With this patchset, following experiment was performed:
    
    Created a highly fragmented disk of size 65TB. The disk had no
    contiguous 2M regions. Following command was run consecutively for 3
    times:
    
    time dd if=/dev/urandom of=file bs=2M count=10
    
    Here are the results with and without cr 0/1 optimizations introduced
    in this patch:
    
    |---------+------------------------------+---------------------------|
    |         | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
    |---------+------------------------------+---------------------------|
    | 1st run | 5m1.871s                     | 2m47.642s                 |
    | 2nd run | 2m28.390s                    | 0m0.611s                  |
    | 3rd run | 2m26.530s                    | 0m1.255s                  |
    |---------+------------------------------+---------------------------|

The timings are done with a freshly mounted file system; the
prefetched block bitmaps plus the mballoc optimizations more than
doubles the time to allocate a 20 MiB file on a highly fragmented file
system.

Cheers,

					- Ted