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

[Mike Looijmans]

On 19-02-19 21:45, Leon Woestenberg wrote:
> 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.

That'd be best. One would expect that creating a filesystem "offline" would 
yield something optimal in terms of the way files are allocated, since 
everything about all files is already known when it's written.

My current workaround is to just mount the device and unpack the rootfs tar 
onto that, which yields a filesystem that u-boot can read at normal speed.


>>> 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>

I'll give it a try...

You mentioned "two" commits?