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

RE: Major JFFS2 bug (?)



Ok, fair enough. Thanks for engaging in the debate.

Do you know of any programs or libraries or (micro) db's that can do this at
the app level? If there aren't any, maybe I can start a open source project
that will help all that need this functionality with JFFS/2.

Vipin


-----Original Message-----
From: Alan Cox
To: Vipin.Malik@xxxxxxx.com
Cc: alan@xxxxxxx.org;
jffs-dev@xxxxxxx.com
Sent: 5/12/01 5:55 PM
Subject: Re: Major JFFS2 bug (?)

> >The question 'what does a complete operation mean' is application
> >specific.
> 
> All true statements, and I don't disagree with any of them, except-
why
> can't we say that if we define "a complete operation", as asked by you

Because it happens to suit one specific app ? Umm I dont think you
follwed my
point. You are talking about hard to implement things that serve just
your
needs for this one app. Suppose for example there is 200K free and I do
a 400K
over write of existing data. Now what happens ?


> If you bear with me and follow the reasoning: JFFS was designed with
this
> express purpose in mind. It *does* already implement "roll back" to
older

No JFFS was designed to come back after random power failures, to wear
level
and to sidestep irritating and silly patents. It wasnt designed to do 
transactions for your app.

> this granuality is available to the app level (as a single system
write()
> call is broken up into multiple jffs2_write() calls). I am making a
case, if
> possible, for exporting this feature at the system write() command
interface
> for the app level to use. Why is that too much to ask?

You want to clutter the kernel to solve an app specific problem. One
with a lot
of quite simple solutions including markers and garbage collection

Alan

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