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

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

Is the behavior under discussion the same or different from JFFS1?
My concern would be that JFFS1 users planning to migrate to JFFS2 when
it is ready will have problems if the behavior is different.

> -----Original Message-----
> From:	Vipin Malik [SMTP:Vipin.Malik@xxxxxxx.com]
> Sent:	Tuesday, May 15, 2001 1:43 PM
> To:	'David Woodhouse '
> Cc:	'''Bjorn Wesen ' ' '; ''''jffs-dev@xxxxxxx.com ' ' ' '
> Subject:	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

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