blkdev/dosfs/emmc issues.

[Tasslehoff Kjappfot]

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 =
FAT_GET_BR_FAT32_ROOT_CLUSTER(boot_rec);

We seem to get no corruption if we add the following line at the top of
msdos_shutdown:

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
cause problems.

Are we on to something?

Tasslehoff

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
>>>> md5sum
>>>> 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
>>>> where
>>>> 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
>>> file.
>>
>> Thanks for the tip.
>>
>>