Re: Major JFFS2 bug (?)

[David Woodhouse <dwmw2@xxxxxxx.org>]

Vipin.Malik@xxxxxxx.com said:
>  My argument is to put the roll back and recover mechanism inside the
> JFFS2_write() handling, the other argument is for the users to handle
> it themselves when they need it. 

Your original statement was that the current lack of atomicity of writes 
w.r.t. power failure was a bug.

That point is what's being denied with some vehemence. I'm unconvinced
either way, but because write() is permitted to return having written fewer
data than it was requested to, I don't think it matters - because even if it
_is_ against the spec you can't prove it actually happened that way. You 
can't distinguish a power failure in the middle of a write from a power 
failure immediately after a short write.


Vipin.Malik@xxxxxxx.com said:
> My argument is to put the roll back and recover mechanism inside the
> JFFS2_write() handling, the other argument is for the users to handle
> it themselves when they need it.

> In the system implementation method *all* programs can natively
> utilize this feature. It needs to be coded once, tested once- then
> it'll always work. That's the advantage. 

That's not an unreasonable feature request, when phrased as a feature
request not a bug report. Doing transactions directly on the flash rather
than through an extra layer of indirection can be a good thing - after all,
that's half the reason why JFFS{,2} is considered far better than emulating
a block device and then using a 'normal' journalling filesystem, isn't it? 
Otherwise, the extra layer of abstraction - journalling upon journalling - 
translates directly into more wear on the flash chips than is otherwise 
necessary.

It's also a feature which at first ponderance seems like it could be
reasonably simple to implement and relatively unobtrusive.

I'm not about to write it myself, but if you want to present a design for 
consideration, I certainly won't dismiss it out of hand.

I believe ext3 exposes transactions to userspace for use by Intermezzo. 
Take a look at the API used for that. Also consider the requirements of 
database backends.

--
dwmw2



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