blkdev/dosfs/emmc issues.

[Sebastian Huber]

I fixed a couple of FAT file system bugs yesterday on the Git master. It 
would be great if you could provide a self-contained test case for your 
issue. See for example "testsuite/fstests/fsdosfsname02".

On 17/03/17 10:20, Tasslehoff Kjappfot wrote:
> 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.
>>>
>>>
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.