fs: ext4: File system errors after writing to ext4 partition

Christian Theiss christian.theiss at janitza.de
Mon Apr 11 10:35:52 CEST 2022


Dear community,

we are getting file system errors on an ext4 partition (that wasn't
shut down properly in linux before) after writing to it from u-boot.
At the moment we are using v2019.01 with some application specific
code that communicates over text files with the update code in the
main application running on linux.

But we can reproduce the behaviour on the current version (2022.04) in
the sandbox with these steps:
--------
[1] create an empty test partition (our partition in the application has 100MB):
    ~> dd if=/dev/zero of=test.bin bs=8M count=1
    1+0 records in
    1+0 records out
    8388608 bytes (8.4 MB, 8.0 MiB) copied, 0.00804182 s, 1.0 GB/s

[2] create the filesystem:
    ~> mkfs.ext4 -O ^metadata_csum test.bin
    mke2fs 1.45.5 (07-Jan-2020)
    Discarding device blocks: done
    Creating filesystem with 2048 4k blocks and 2048 inodes

    Allocating group tables: done
    Writing inode tables: done
    Creating journal (1024 blocks): done
    Writing superblocks and filesystem accounting information: done

[3] mount the filesystem:
    ~> mount -o loop,rw test.bin mnt

[4] create a test file and make sure it is written
    ~> echo test > mnt/test.txt
    ~> sync

[5] simulate power loss by dd'ing the file while it is mounted
    ~> dd if=test.bin of=test_notclean.bin
    16384+0 records in
    16384+0 records out
    8388608 bytes (8.4 MB, 8.0 MiB) copied, 0.0307814 s, 273 MB/s

[6] a fsck (without -f option) shows and fixes some minor issues. A
fsck with -f finds no more issues:
    ~> cp test_notclean.bin test_check.bin
    ~> e2fsck test_check.bin
    e2fsck 1.45.5 (07-Jan-2020)
    test_check.bin: recovering journal
    Setting free inodes count to 2036 (was 2037)
    Setting free blocks count to 949 (was 950)
    test_check.bin: clean, 12/2048 files, 1099/2048 blocks

    ~> e2fsck -f test_check.bin
    e2fsck 1.45.5 (07-Jan-2020)
    Pass 1: Checking inodes, blocks, and sizes
    Pass 2: Checking directory structure
    Pass 3: Checking directory connectivity
    Pass 4: Checking reference counts
    Pass 5: Checking group summary information
    test_check.bin: 12/2048 files (8.3% non-contiguous), 1099/2048 blocks

[7] Write to the partition in u-boot sandbox and abort with CTRL-C:
    ~> ./u-boot
    U-Boot 2022.04 (Apr 08 2022 - 15:20:04 +0200)

    DRAM:  128 MiB
    Core:  16 devices, 12 uclasses, devicetree: board
    MMC:
    Loading Environment from nowhere... OK
    Warning: device tree node '/config/environment' not found
    In:    serial
    Out:   serial
    Err:   serial
    SCSI:
    Net:   No ethernet found.
    Hit any key to stop autoboot:  0
    ## Error: "distro_bootcmd" not defined
    => host bind 0 test_notclean.bin
    => ext4write host 0 0x0 /test.txt 1
    Journal Scan Completed
    Recovery required
    Journal Recovery Completed
    file found, deleting
    update journal finished
    File System is consistent
    update journal finished
    1 bytes written in 8 ms (0 Bytes/s)
    =>

[8] Similar to before, the quick fsck corrects the number of free inodes:
    ~> cp test_notclean.bin test_check.bin
    ~> e2fsck test_check.bin
    e2fsck 1.45.5 (07-Jan-2020)
    Setting free inodes count to 2036 (was 2037)
    test_check.bin: clean, 12/2048 files, 1100/2048 blocks

[9] But now the -f fsck finds some more issues:
    ~> e2fsck -fy test_check.bin
    e2fsck 1.45.5 (07-Jan-2020)
    Pass 1: Checking inodes, blocks, and sizes
    Pass 2: Checking directory structure
    Pass 3: Checking directory connectivity
    Pass 4: Checking reference counts
    Pass 5: Checking group summary information
    Block bitmap differences:  -1098
    Fix? yes

    Free blocks count wrong for group #0 (948, counted=949).
    Fix? yes

    Free blocks count wrong (948, counted=949).
    Fix? yes

    test_check.bin: ***** FILE SYSTEM WAS MODIFIED *****
    test_check.bin: 12/2048 files (8.3% non-contiguous), 1099/2048 blocks
--------

Note: If I don't execute step [7] and mount the prepared partition in
linux, write to it and unmount it, fsck shows no errors afterwards.

I hope this information can help to reproduce the problem and fix it.
As a short-term workaround we are doing a -f fsck on every boot in our
application.

Regards,
Christian Theiss

-- 
*Janitza electronics GmbH
*Vor dem Polstück 6 | 35633 Lahnau | Germany
Telefon +49 6441 9642-0



 <https://www.janitza.de>



*www.janitza.de* 
<http://www.janitza.de/>* | **Janitza Youtube Channel* 
<https://www.youtube.com/channel/UCraj3qQHQIqXIfcyUcAgpFw>* | **Janitza auf 
Facebook* <https://www.facebook.com/pages/Janitza/1638022523098974>

  


Geschäftsführer: Markus Janitza, Rudolf Müller
Handelsregister: HRB 928 
Wetzlar
USt.-IdNr.: DE 112 616 565
Steuernummer: 02 02 365 0179 
<http://sl.janitza.de/maillink_DE>



More information about the U-Boot mailing list