RFS data loss for open files and ways to work around it
sebastian.huber at embedded-brains.de
Mon May 9 11:09:55 UTC 2016
On 09/05/16 10:13, Mohammed Saeed Khoory wrote:
>> On 09/05/16 07:32, Mohammed Saeed Khoory wrote:
>>> 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.
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
> 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.
More information about the users