sebastian.huber at embedded-brains.de
Fri Mar 17 09:29:33 UTC 2017
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 =
> 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
> cause problems.
> 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.
> users mailing list
> users at rtems.org
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.
More information about the users