Missing call to flush after format

[Ralino]

Describe the bug

fx_media_format does not call the underlying I/O driver with FX_DRIVER_FLUSH after writing the boot sector and root directory sectors and before uninitializing the driver with FX_DRIVER_UNINIT.

Depending on the I/O driver implementation, this can lead to format not being fully applied to the media, leaving the filesystem in an invalid state.

We are using dhara as the flash translation layer and for wear-leveling. Dhara uses a journal for mapping physical pages to logical pages. This journal will not be persisted on every write, but only on certain checkpoints. To ensure a persisted state, dhara provides the function dhara_map_sync, which we have mapped to the FX_DRIVER_FLUSH I/O driver request. On initialisation (dhara_map_init and dhara_map_resume, which we have mapped to FX_DRIVER_INIT), dhara recovers the state from the last checkpoint.

Thus, when formatting the media with fx_media_format and then opening it with fx_media_open, some writes done during formatting might be lost, which in our case lead to corrupted root directories.

We are using FileX together with ThreadX on an STM32H7. The total clusters calculated by fx_file_format on our media is smaller than 64K, thus it will be formatted as FAT16, with a fixed root directory initialised by fx_file_format as well.

To Reproduce
Steps to reproduce the behavior:

1. call fx_media_format

Actual behavior
The I/O driver is called with:

• FX_DRIVER_INIT
• FX_DRIVER_BOOT_WRITE
• FX_DRIVER_WRITE multiple times
• FX_DRIVER_UNINIT

Expected behavior
The I/O driver is called with:

• FX_DRIVER_INIT
• FX_DRIVER_BOOT_WRITE
• FX_DRIVER_WRITE multiple times
• FX_DRIVER_FLUSH
• FX_DRIVER_UNINIT

Impact
Workarounds are possible, for example flushing the driver on FX_DRIVER_UNINIT as well. However, the documentation does not suggest that this should be necessary, and fx_media_close also explicitly calls FX_DRIVER_FLUSH before closing it with FX_DRIVER_UNINIT.