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:
- call
fx_media_format
Actual behavior
The I/O driver is called with:
FX_DRIVER_INITFX_DRIVER_BOOT_WRITEFX_DRIVER_WRITE multiple timesFX_DRIVER_UNINIT
Expected behavior
The I/O driver is called with:
FX_DRIVER_INITFX_DRIVER_BOOT_WRITEFX_DRIVER_WRITE multiple timesFX_DRIVER_FLUSHFX_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.
Describe the bug
fx_media_formatdoes not call the underlying I/O driver withFX_DRIVER_FLUSHafter writing the boot sector and root directory sectors and before uninitializing the driver withFX_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 theFX_DRIVER_FLUSHI/O driver request. On initialisation (dhara_map_initanddhara_map_resume, which we have mapped toFX_DRIVER_INIT), dhara recovers the state from the last checkpoint.Thus, when formatting the media with
fx_media_formatand then opening it withfx_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_formaton our media is smaller than 64K, thus it will be formatted as FAT16, with a fixed root directory initialised byfx_file_formatas well.To Reproduce
Steps to reproduce the behavior:
fx_media_formatActual behavior
The I/O driver is called with:
FX_DRIVER_INITFX_DRIVER_BOOT_WRITEFX_DRIVER_WRITEmultiple timesFX_DRIVER_UNINITExpected behavior
The I/O driver is called with:
FX_DRIVER_INITFX_DRIVER_BOOT_WRITEFX_DRIVER_WRITEmultiple timesFX_DRIVER_FLUSHFX_DRIVER_UNINITImpact
Workarounds are possible, for example flushing the driver on
FX_DRIVER_UNINITas well. However, the documentation does not suggest that this should be necessary, andfx_media_closealso explicitly callsFX_DRIVER_FLUSHbefore closing it withFX_DRIVER_UNINIT.