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

RE: Major JFFS2 bug (?) No! Feature request? Yes!



David Woodhouse wrote:
>Your original statement was that the current lack of atomicity of writes
>w.r.t. power failure was a bug.

That's a correct statement. It was based on my (now obviously invalid, at
the very least misplaced) assumption that this feature was already part of
JFFS(2)! I wasn't sure, that's why I had the "(?)" in the subject.


>That point is what's being denied with some vehemence.

Ah! Now that you put it in so many words it makes sense :) I had moved
passed my original contention of it being a "bug" long ago. I've been
arguing for the to be a feature for a while now :) My fault for not
communicating that more clearly.


> I'm unconvinced
>either way, but because write() is permitted to return having written
>fewer
>data than it was requested to,

There is no debating that. That's the current implementation. But does it
*have* to be?

> 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.


The important point is not a "short" write. If the user takes care of
"collecting" all their important data into a single write, then they can
tell if the write failed to write all or none of the data or did a portion
of it. All or non is fine, portion (what I'm arguing for) is not.

For users that are doing multiple short overwrites of existing data, this
debate is a non-issue- I agree.

>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.


That's what I would say!


>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.

Hmm, by "present a design" do you mean, show us a working implementation? I
presented a very rough algorithm. I could refine it a bit more, but coding
this feature myself, would first mean figuring out the subtleties of JFFS2.
It's most reliably and efficiently implemented by someone that still has the
details of the JFFS2 workings fresh in their mind. Know someone with those
qualifications? ;) 

>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.

I can *attempt* to look at this, but it is probably way beyond my present
abilities. Care to give me some place to start?

Vipin

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