[OE-core] wic creates ext4 images that read really slow in u-boot

[Leon Woestenberg]

Hello all,

On Tue, Feb 19, 2019 at 8:28 PM Andre McCurdy <armccurdy at gmail.com> wrote:
> On Tue, Feb 19, 2019 at 9:13 AM Leon Woestenberg <leon at sidebranch.com> wrote:
>>
>> Hello Mike,
>>
>> sounds familiar.
>>
>> On Tue, 19 Feb 2019 at 17:55, Mike Looijmans <mike.looijmans at topic.nl> wrote:
>>>
>>> Took me a while to figure out why my board took 90 seconds to boot suddenly.
>>> The issue turned out to be the ext4 partition created by wic.
>>
>> I suspect it's not WIC's fault.
>>>
>>> ZynqMP> load mmc 0:2 0x100000 /lib/firmware/fpga.bin
>>> 19311092 bytes read in 85529 ms (219.7 KiB/s)
>>>
>>> Now if I boot the board rename and copy that file onto itself, then it's
>>> suddenly normal again when I reboot the board:
>>>
>>> ZynqMP> load mmc 0:2 0x10000
>>> I'm not knowledgeable on ext4, so any ideas what's being passed onto the image
>>> creation tool that causes this?
>>
>> I suspect your version of U-Boot does not handle files spread across multiple filesystems (allocation) extends efficiently.
>>
>> Copying the file makes the copy being layed out in one extend probably.
>
>
> If WIC is generating filesystem images from scratch there's no excuse for files to be unnecessarily fragmented.
>
> Even if some of all of the boot time can be recovered by a patch to u-boot that won't help systems which have already been deployed and don't have a way to update the bootloader.
>
I am not sure if "fragmented" is the right term in terms of filesystem
details. Filesystem allocation extents (not "extends" as I mistyped
earlier) are different from heavy file fragmentation. However, I agree
things can be made more optimal.

So, with adding the above, there are *two* issues at play here:
1) Most/older versions of U-Boot not able to efficiently load files
from ext4 filesystems, that cross multiple extents. I am aware of two
fixes, see below.
2) WIC uses mkext4fs in such a way that files can cross multiple
(allocation) extents. This is sub-optimal and know to cause issues
with many U-Boot versions (deployed on existing systems in the field).
The problems shows "randomly" with large files being deployed to the
ext4 filesystem. We (OE/Yocto) may want to fix this.

>> I am aware of two fixes for U-Boot. I will look them up, and reply again to this thread.

Google for these two commits. I cherry-picked the first one for my
project and can confirm it brings back the desired performance. (Still
assuming this is the identical cause as for TO/Mike.)

commit 855b8e4f9f255415a7753819e392e4b5d984f35c
Author: Matt Madison <matt at madison.systems>
Date:   Sat Aug 19 08:46:46 2017 -0700

    ext4: cache extent blocks during file reads

    A simpler and less-efficient approach to solving
    the problem with extent index blocks than what
    was in fc0fc50f38a4d7d0554558076a79dfe8b0d78cd5,
    but one that does not break write operations.

    Signed-off-by: Matt Madison <matt at madison.systems>

Regards,

Leon.

p.s. excuse the earlier HTML mail with signature