It turns out that this bug was fixed last year
author Sebastian Huber 2017-09-06 12:30:00 (UTC) committer Sebastian Huber 2017-09-06 12:40:38 (UTC) dosfs: Fix fat_file_update() Do not update the non-existant meta-data of the root directory. Close #2944. Apparently I have been working with an old snapshot of dosfs. I hate it when that happens! Sorry for not checking before posting a question. Cliff -----Original Message----- From: Chris Johns Sent: Tuesday, October 02, 2018 6:32 PM To: Cliff Geschke; Subject: Re: How to sync a dos file system externally On 03/10/2018 04:56, Cliff Geschke wrote: > I have implemented a dos file system (msdos_*) on a flash device. Is the flash device a chip you have direct access too? The reason I ask is if possible using JFFS2 (a journaling file system) or even YAFFS (commercial license maybe needed) is a better solution. > Because it is possible for the user to power down the system unexpectedly, I > want to sync the file system to the flash device after a 3 second idle time. > How do I externally force a sync on msdos from another thread? The following test ... https://git.rtems.org/rtems/tree/testsuites/fstests/fsdosfssync01/init.c shows how to purge a disk at the block layer. Wrap something like this is the way to purge the cache. > A related problem is that I use FTP (ftpd.c) to externally read/write files on > the msdos formatted flash. I have the idle timeout set to 3 minutes for the FTP > connection. After 3 minutes, ftpd issues a chdir("/") which eventually calls > msdos_free_node_info() that calls fat_file_close() and may try to write out data > to the flash. This is a problem because if the power is turned off at that time > the flash is corrupted. > > So whatever method I use to sync msdos needs to update and write out the fat so > that the subsequent msdos_free_node_info() does nothing. I should point out there is a finite chance the disk can still become corrupted. How small the window becomes depends on the system design, for example how often the disk is updated, power supply power down storage vs media write time, non-bricking read-only partitions, etc. I suspect triggering a timer to purge the cache as shown above is no different to lowering the `swapout` task's period. It has been a while since I looked over this code. The libblock cache implements separate threads to "sync" the cache to the media on a periodic basis. The cache's configuration lets you set the period. The values are documented here: https://docs.rtems.org/doxygen/branches/master/group__rtems__bdbuf.html#define-m embers This however raises a difficult question which is documented in the code in a comment: https://git.rtems.org/rtems/tree/cpukit/libblock/src/bdbuf.c#n1013 It is difficult when using a timer to know if the purge is 100% safe. If you can arrange the purge call to happen after you know the update has finished it lowers the chance the disk maybe become corrupted. Chris
_______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
