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

[Jack Mitchell]

On 19/02/2019 20: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.
> 
>>> 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
> 

I can concur that I have also used this patch to fix speed issues with
ext4 reads. The problem becomes particularly prominent when you have
large files on a small partition which get over-written. I'm sure I have
seen a patch go into uboot mainline recently which improved performance
but I can't find it or it never actually made it into the tree.