Filesystem stack behaviour after force SD card eject

[Sebastian Huber]

Hello Oliviu,

On 05/07/2019 23:05, Gabor, Oliviu wrote:
> Hello all,
> 
> I have the following questions about using the FAT Filesystem stack
> from RTEMS.
> When interfacing with an SD Card, I do these steps:
> - open a file on the successfully mounted device
> - execute some RW operations on the file
> - execute fflush() and fclose()
> - manually eject the SD card from the slot
> 
> At some point during the shutdown procedure, The FS will call the
> fat_fat32_update_fsinfo_sector() to syncronize the fsinfo sector.
> Because I didn't manually fsync-ed the device before ejecting the SD
> card, the FS will try to do it, issueing read/write commands to the
> device, which is no longer present in the card slot. From this point
> on, re-insertion of the SD card will fail until the SD controller is
> reset.
> 
> My questions:
> 1. should the user be the sole responsible for manually calling fsync()
> after RW operations are performed?
> 2. is it normal that the FS stack crash in case card is ejected without
> proper callin fsync()?
> 
> This issue does not occur if before ejecting I call fsync().
> 
> My point is that regardless if the user loses data in case card is
> ejected, the FS stack should still need to be able to be reinitialized
> after an unsuccessfull unmount/eject of the device.

For USB mass storage devices it works. The media manager takes care of 
this. Here is an example:

https://git.rtems.org/rtems-libbsd/tree/testsuite/media01/test_main.c

The SD card driver must deal with requests to a non-existing card and 
return ENXIO errors in this case.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.