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

[Mohammed Saeed Khoory]

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

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.