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

[Mohammed Saeed Khoory]

Thanks. I will check out that example.

I've considered switching to 4.11 several times already, but I'm waiting for a stable release first. Until then the workaround I mentioned is working fine, despite the silly complexity and overhead it adds. I hope it helps for anyone facing the same issue.


> -----Original Message-----
> From: Sebastian Huber [mailto:sebastian.huber at embedded-brains.de]
> Sent: Monday, May 09, 2016 3:10 PM
> To: Mohammed Saeed Khoory; 'rtems-users at rtems.org'
> Subject: Re: RFS data loss for open files and ways to work around it
> 
> 
> 
> 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_suppo
> rt.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.