How to sync a dos file system externally

[Christian Mauderer]

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 at rtems.org
> http://lists.rtems.org/mailman/listinfo/users
>