ext4: invalid extent block on imx7

[Jan Kiszka]

On 25.03.20 16:00, Tom Rini wrote:
> On Wed, Mar 25, 2020 at 07:32:30AM +0100, Jan Kiszka wrote:
>> On 20.03.20 19:21, Tom Rini wrote:
>>> On Mon, Mar 16, 2020 at 08:09:53PM +0100, Jan Kiszka wrote:
>>>> Hi all,
>>>>
>>>> => ls mmc 0:1 /usr/lib/linux-image-4.9.11-1.3.0-dirty
>>>> CACHE: Misaligned operation at range [bdfff998, bdfffd98]
>>>> CACHE: Misaligned operation at range [bdfff998, bdfffd98]
>>>> CACHE: Misaligned operation at range [bdfff998, bdfffd98]
>>>> CACHE: Misaligned operation at range [bdfff998, bdfffd98]
>>>> invalid extent block
>>>>
>>>> I'm using master (50be9f0e1ccc) on the MCIMX7SABRE, defconfig.
>>>>
>>>> What could this be? The filesystem is fine from Linux POV.
>>>
>>> Use tune2fs -l and see if there's any new'ish features enabled that we
>>> need some sort of check-and-reject for would be my first guess.
>>>
>>
>> Here are the reported feature flags:
>>
>> has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg
>> sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
> 
> Of that, only metadata_csum means that you can't write to that image,
> but you're just trying to read and that should be fine.  Can you go back
> in time a little and see if this problem persists or if it's been
> introduced of late?  Or recreate it on other platforms/SoCs?  Thanks!
> 

Bisected, regression of d5aee659f217 ("fs: ext4: cache extent data"). 
Reverting this commit over master resolves the issue.

Any idea what could be wrong? What I noticed is that the extent has a 
zeroed magic when things go wrong, so maybe it is falsely considered to 
be cached?

Jan

>> Anything too fancy in here? But the method of creating this filesystem does
>> not deviate from many other setups we have for U-Boot (on other boards).
> 
> Yes, but for some time now e2fsprogs has introduced new default features
> that require compatibility checks.
> 

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux