[ECOS] Re: fatfs help.

Andrew Lunn andrew@lunn.ch
Fri Sep 17 10:43:00 GMT 2004

On Thu, Sep 16, 2004 at 08:31:49PM -0700, David Brennan wrote:
> More info:
> fileio1.c works great on the CF (minus the file.max test).
> However, I still cannot delete files permanently from within my 
> application. I believe the difference is that the end of fileio1.c code 
> umounts root. I do not have that luxury. I have seen posts referencing 
> needing to do an fsync(). But how do I fsync the directory after 
> deleting a file?

Savin is the expert in this area, but he is on Holiday at the moment.

Basically if anybody can pull the disk at any time, you have to expect
some level of corruption. You can however minimise this. You basically
need the filesystem to use write through caching. At the moment you
cannot control this. You need to look at all the operations in fatfs.c
and decide which ones can change what should be on the disk. To these
add code something like:

This will flush the block layer cache. 

This is a step forward, but their is still room for improvement. The
block cache does not keep track of order information. You first remove
the file from the directory inode and then free the blocks back into
the pool. Doing it this way it does not matter too much if the disk is
pulled part way through the operation. The file has gone from the
directory so if half the blocks are back in the pool and half are
still allocated is not so importent. There is no user visible
corruption. But the current code does not maintain ordering
information, so it code free the blocks and never get around to
removing the file from the directory inode.

You have to decide how much effort you want to spend on this vs how
well you can train you users to not pull the disk until they are told
it is safe to do so.


Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

More information about the Ecos-discuss mailing list