RFS data loss for open files and ways to work around it

[Sebastian Huber]

On 09/05/16 10:13, Mohammed Saeed Khoory wrote:
>   
>> On 09/05/16 07:32, Mohammed Saeed Khoory wrote:
>>> Hi,
>>>
>>> I'm using RFS on a RAMDisk for a LEON3-based system. My program tends to
>> keep files open while writing to them periodically. I've noticed that if
>> the system was reset, the files that were open lose all of the data that
>> was written since they were last open. The files still exist in the
>> filesystem, just with a size of 0. Interestingly however, the free space
>> blocks used by those writes are not reclaimed and is gone, and the only
>> way to get it back from what I can tell is to reformat. An fsck-style tool
>> would probably work too but that doesn't exist.
>>
>> Even if you flush your data to disk, then this file systems seems to be
>> not reset-safe. JFFS2 could be an option for such scenarios.
>>
> Would JFFS2 be appropriate to use on a RAMDisk? From what I understand it's designed for use on flash devices only and won't work well on other types of block devices.

See

https://git.rtems.org/rtems/tree/testsuites/fstests/jffs2_support/fs_support.c

which uses normal memory for the storage device.

>
> Anyways, I noticed that JFFS2 wasn't added in 4.10.2, which is what I'm using, so I can't go that route.
>
>>> The way I work around this is that instead of keeping files open, I open
>> the file, write a little, then close instantly. The changes are then
>> preserved in the filesystem if a reset occurs. However, this method is
>> rather awkward, and I was wondering if there's a better way of doing it.
>> I've tried using fflush() and sync(), but that didn't help. Is there a
>> proper way to "synchronize" the writes to the filesystem?
>>
>> The sync() implementation is not really useful in RTEMS. However,
>> fsync() should work. I guess for standard C FILE files you need a
>>
>> fflush(file);
>> fsync(fileno(file));
>>
>>
> Sorry, I meant to say I used fsync(); I'm using POSIX fd's not standard C FILEs. It still doesn't work entirely, but after trying it some more, I noticed that it sometimes works, but not all the time. I think it depends on how long the file was open for, or how much is written, but I can't really tell.
>
> Thanks for the help. I'm leaning towards sticking to my workaround for now.

Between RTEMS 4.10 and 4.11 a lot changed in the file system 
infrastructure. I would consider to update to 4.11. A sporadically 
working fsync() is pretty worthless.

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