[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Major JFFS2 bug (?)
On Tue, 15 May 2001, Vipin Malik wrote:
> With JFFS2, if you are overwriting data to an existing file
> and power crashes, you may endup with a file that has *some*
> old data and *some* new data.
Well that was what I wrote as well - if you overwrite existing data (as
opposed to first truncating the file and rewriting it, which does not have
this problem) you might get into the situation that half the data was
written and the other half was not.
Please note that this debate is a matter of principle and standards. The
structure on flash certainly can handle the atomic transaction of a
data-update, _provided there is enough room to do so without GC_.
> The "atomicity" of the write() with respect to power fail is
> NOT guaranteed. I have proved this with JFFS2.
> In my debate with Alan Cox, I argued for power fail safe write()'s.
> Alan debated that the kernel should not gurantee that, and if the
> user needs it, they need to handle it on their own.
I know, I read it. It's a matter of standards. It's "ugly" trying to get
that into the normal Linux / POSIX framework. write() is specified to
being able to write less than the requested amount and there is nothing
you can do about it.
You'll see the assumption of write/read being "atomic" in a lot of network
code (people should know better) causing all kinds of weird bugs. For
example servers that only responds to commands that happen to arrive in
the same packet.. we've had our own share of those bugs, and so has
Microsoft (and probably still have :)
> As of now, this is not being classified as a bug, but a known feature.
> I was hoping that some other folks would pipe up re. this and their
> expectations, but no one else has.
I think it's mostly a matter of API. As I wrote, the system itself can
handle the situation you ask for. You could probably extend a filesystem
ioctl that takes a "control block" and performs an atomic transaction with
it in a completely non-standard way for example.
To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to firstname.lastname@example.org