tasskjapp at gmail.com
Fri Mar 17 09:20:19 UTC 2017
We have narrowed this down a bit, and I want to run something by you. It
seems the unmount of a FAT filesystem can cause random overwrites.
The sequence msdos_shutdown -> fat_file_close -> fat_file_update causes
the driver to operate on cluster #1 (set in (fat_fd->dir_pos.sname.cln).
The rootdir cluster is not #1, and it seems to be taken from the define
FAT_ROOTDIR_CLUSTER_NUM that is used a couple of places in the code.
The rootdir cluster found in fat.c is #2. // vol->rdir_cl =
We seem to get no corruption if we add the following line at the top of
fat_fd->dir_pos.sname.cln = 2 // should get this from rdir_cl
I suspect that the other places FAT_ROOTDIR_CLUSTER_NUM is used can also
Are we on to something?
On 03/13/17 16:36, Gedare Bloom wrote:
> On Mon, Mar 13, 2017 at 11:05 AM, Tasslehoff Kjappfot
> <tasskjapp at gmail.com> wrote:
>> On Mon, Mar 13, 2017 at 3:48 PM, Gedare Bloom <gedare at rtems.org> wrote:
>>> On Mon, Mar 13, 2017 at 9:42 AM, Tasslehoff Kjappfot
>>> <tasskjapp at gmail.com> wrote:
>>>> A little update on this. I found out that if I do the following, the
>>>> is wrong the second time I check it.
>>>> 1. Write upgrade files
>>>> 2. Check MD5
>>>> 3. Unmount
>>>> 4. Mount
>>>> 5. Check MD5
>>> What is the return value from unmount?
>> unmount is successful every time.
> I did not think dosfs supports unmount() function so this is
> surprising to me. How do you call it?
>>>> If I do not unmount/mount, the MD5 is ok, even after a reboot.
>>>> With JTAG I discovered that after I have initiated an unmount, the
>>>> bdbuf_swapout_task tries to do 3 writes into blocks inside the file
>>>> the MD5 check fails. If I just ignore those writes, it also works.
>>> Now that is strange. It may be worth it to inspect the
>>> bdbuf_cache.modified and bdbuf_cache.sync chains. Those are what the
>>> swapout task processes. A guess is maybe there is a race condition
>>> between the two lists when the sync happens, and you are getting a
>>> couple of extra writes.
>> Sounds plausible. Is it possible to bypass/disable the bdbuf cache
>> altogether? I have not configured anything related to SWAPOUT in my
>> application, and the BDBUF setup is the following.
> You can't entirely avoid it without changing the filesystem you use.
>> #define CONFIGURE_BDBUF_MAX_READ_AHEAD_BLOCKS (16)
>> #define CONFIGURE_BDBUF_MAX_WRITE_BLOCKS (64)
>> #define CONFIGURE_BDBUF_BUFFER_MIN_SIZE (512)
>> #define CONFIGURE_BDBUF_BUFFER_MAX_SIZE (32 * 1024)
>> #define CONFIGURE_BDBUF_CACHE_MEMORY_SIZE (4 * 1024 * 1024)
> You may like to define a smaller CONFIGURE_SWAPOUT_BLOCK_HOLD
> (and a smaller CONFIGURE_SWAPOUT_SWAP_PERIOD).
> These two control the delay before swapout writes to disk.
>>> You might also like to enable RTEMS_BDBUF_TRACE at the top of bdbuf.c
>> Thanks for the tip.
More information about the users