[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.
Basically if your application needs to be able to do roll back and recovery
then for almost all cases but the most trivial it needs to do them itself.
It is physically impossible to guarantee multiple disk writes occur in a
sudden power off case.
> >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
Don't rely on that. JFFS2 can change the synchronization policy at will. If
you specify O_SYNC then you are guaranteed that the data is written
> 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.
JFFS has to address one specific problem. The user can turn the box off at
any moment. JFFS has to recover to a consistent state when this occurs.
> 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.
That is an application level problem..
> 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.
So deal with it at the application level. Now that isnt OS designers trying to
pass the buck, its a considered policy. It is rare that the application view
of atomicity in any way matches file level atomicity. Often an application is
working on sets of files or multiple blocks.
The unix password command for example takes great care to generate a new file,
then rename it over the old one in order to be sure either one or the other
file is consistent.
The question 'what does a complete operation mean' is application specific.
To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to firstname.lastname@example.org