#18 FAT Table not completely flushed if NUMCACHES > 1

open-fixed
nobody
None
5
2008-11-18
2008-11-18
No

When the cache has a value greater than 1, then the FAT table doesn't get written to the disk. When the file is closed (even with the previous patch relating to flushing).

That patch works great and fixes the caching mechanism, for example mkdir will suceed when the cache is greater than 0.

I'm not sure if this is the best fix, but for now it solves the problem.

On each fclose, I flush the entire cache to the SDCARD. I'm not too sure how this will affect multiple file-opens.

I have included my patch below regarding file.c in the 0.2.8 version of EFSL.

James

email: james at worm dot me dot uk

Discussion

  • James Walmsley

    James Walmsley - 2008-11-18

    Patched file.c with Fix

     
    Attachments
  • James Walmsley

    James Walmsley - 2008-11-18
    • status: open --> open-fixed
     
  • James Walmsley

    James Walmsley - 2008-11-20

    Caution with this patch, it works fine when onlx having a single file open at a time. (The same as EFSL before the patch).

    If there are multiple files open at the same time, then sometimes there can be problems. Currently I have 2 files being constantly appended to. Mostly if I ls the directory i'm writing the files to, everything is ok.

    But sometimes it goes wrong, and suddenly the file-sizes happen to decrease, i.e. EFSL starts writing from the start again. Somehow, the ls operations ls_openDir etc causes some problems here.

    If you just leave it to do its business nothing goes wrong.

    I think the problem comes architecturally, that the EFSL library isn't really designed with multi-threaded environments in-mind. It doesn't seem to handle having multiple files open very well.

    Instead of flushing the entire cache, a flush of only the buffers relating to a specific file would fix this. I can't find a mechanism that would allow me to do this, without creating some other routines.

    James

     
  • James Walmsley

    James Walmsley - 2008-11-20

    Without this patch, the only way to get EFSL to re-write the FAT table is to unmount the partition. Otherwise all data will be on the disk, just not visible.

     
  • James Walmsley

    James Walmsley - 2008-11-21

    Ok I now fully tested my patch. It is safe if you are running EFSL in a thread-safe way. This means, any call to the EFSL library is atomic. I.e. a Semaphore exists around all EFSL function calls, to ensure that only a single context is using EFSL at a time. I.e. no 2 EFSL function calls can occur simultaneously. Otherwise the FS can become corrupted. (Is what happens is that the EFSL cache loses it context, and becomes corrupt and undefined).

    With my patch, this makes this even more critical, i.e. you'll get more problems more often if you don't adhere to this atomic operation policy. Before patching it is still unsafe to have 2 EFSL functions called at the same time, if your lucky you'll be ok, other times you'll cause undefined behaviour.

    I'm currently in the middle of writing a new FAT FS driver, designed for embedded systems, that is thread-safe from the ground up, and will not suffer from these problems. It should be finished (at least a preliminary release) by the end of Jan 2009. Some of my current tests show it to be 300x faster than EFSL.

    It's called FullFAT and you will find it here on sourceforge soon. Till then a google search might find my website.

    (I dont know if its ok to put my address here!)

    Best of luck using EFSL, its really a great well-written project for those who don't need to use a multi-threaded environment.

    James

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks