On Sep 23, 6:07*pm, pes wrote:
> Hi,
>
> When i write to a file which is on JFFS2 file system with a C function,
> can I reboot the system immediately after having closed the file by C
> function ?
>
> Or in other words, at which moment Linux write the file on my flash memory?
>
> Thanks to explain me.

should not be an issue, after u close it, the driver makes sure every
jobs done before closing the file handle

On Tue, 23 Sep 2008 15:07:49 +0200, pes wrote:

> When i write to a file which is on JFFS2 file system with a C function,
> can I reboot the system immediately after having closed the file by C
> function ?
>
> Or in other words, at which moment Linux write the file on my flash
> memory?

After your function, which is really a system call wrapped via libc,
closes the file, it is handled by the filesystem code in the kernel.
It goes through the VFS layer, which normally uses buffer cache, so
the file may not be all written out. The metadata (the filesystem data
that describes that the file exists, etc), is typically journalled,
so even if not written out, it should still be there because replaying
the journal on reboot will get it. This is not true for data in most
cases. To remediate, you should sync(), which causes the buffer cache
to be written out to disk.



--
Przemek Klosowski, Ph.D.

Rebooting the system is supposed to flush all filesystem caches, so
supposedly JFFS2 is not a problem.

But JFFS2 usually sits on an MTD driver. In my system I see a
"mtdblockd" daemon running. I suppose same asynchronously handles
requests to write to the flash. Same will receive a stop signal when
rebooting and might or might not finish it's work (writing data into the
flash and waiting for each data block to be ready) decently.

Maybe there is an interface to monitor mtdblockd and it might be a good
idea to delay the reboot until it's idle.

-Michael

Michael Schnell wrote:
> Rebooting the system is supposed to flush all filesystem caches, so
> supposedly JFFS2 is not a problem.
>
> But JFFS2 usually sits on an MTD driver. In my system I see a
> "mtdblockd" daemon running. I suppose same asynchronously handles
> requests to write to the flash. Same will receive a stop signal when
> rebooting and might or might not finish it's work (writing data into the
> flash and waiting for each data block to be ready) decently.
>
> Maybe there is an interface to monitor mtdblockd and it might be a good
> idea to delay the reboot until it's idle.
>
> -Michael


Thanks to all for explanations. I will do a sync before my reboot.
I think data are not flushed because I d a force reboot ( # reboot -f)