Hello Cliff, please note that this wasn't the only bug that has been fixed over the last year in the fat file system:
https://git.rtems.org/rtems/log/cpukit/libfs/src/dosfs Regards Christian Am 05.10.18 um 18:59 schrieb Cliff Geschke: > 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-members > > > > 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 > _______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
