[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
>fsync and friends are write barriers. But they
>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
>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.
To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to firstname.lastname@example.org