[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Major JFFS2 bug (?)




>If your app cares use file locking. If you need to do application level
>transactions do transactions at the application level.

Alan, could you please elaborate on this a bit.

>Writes can be cached. 

Hmm, Isn't open() with O_SYNC for preventing caching of writes in the VFS?
Plus, I thought JFFS/2 always ran with O_SYNC, regardless how we opened the
file.

>fsync and friends are write barriers. But they
>dont have
>to be.  

>Also random power off is outside the posix definition


Does this mean, that (embedded) linux can't (shouldn't) address the async
power down issue? I know that my (and other's) products have to, regardless
of what POSIX says or doesn't say :) Specially considering the fact that
JFFS/2 was designed for this express goal. I'm not asking for this feature
in a main stream fs like ext2/3 which is designed for throughput and not
async power down reliability.


>write versus write is atomic anyway. See the inode semaphore. for write
>versus
>read use file locking

I aplogize for using "atomic" in a wrong context. I meant it in the context
of "either the entire write takes to the fs or none of it takes" in case
power fails in the middle of the write. I did NOT mean it in the (usual)
context of multiple programs reading/writing to the same file.

A resulting file with half old data and half new data (when overwriting the
old data in the file), just because power failed is not (IHMO and to me from
designing a reliable embedded system) acceptable.

Vipin

To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo@xxxxxxx.com