Re: [Yaffs] FYI: small yaffs2 vs jffs2 comparison

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Charles Manning
Date:  
To: yaffs
Subject: Re: [Yaffs] FYI: small yaffs2 vs jffs2 comparison
On Friday 06 October 2006 19:21, Vitaly Wool wrote:
> On 10/6/06, Charles Manning <> wrote:
> > > Yea, I was surprised with that as well, However, after some
> > > considerations, I'm close to the conclusion that it's
> > > controller-specific. The thing is that the OOB is spread across the
> > > page IOT facilitate HW ECC, so it's (512b data, 16b OOB) x 4 actually
> > > for each page, so each OOB write is costly. However, such things
> > > appear more and more as manufacturers go producing cheaper chips that
> > > need stronger ECC.
> >
> > Well that is a "driver thing" in some ways too. A particular driver that
> > is
> > unfriendly to oob writing will penalise yaffs2. As always, a streamlined
> > custom driver is going to be faster than a generic one, and is the
> > approach
> > taken by almost all those interested in top performance.
>
> I'd like to disagree with you here. It's basically not a "driver thing"
> since it's forced by HW. The "weird" layout is due to the need for the
> controller to be able to perform HW ECC.
> This is a MLC flash chip so it needs strong ECC capabilities, therefore the
> other sensible option would be to have standard data and OOB layout and to
> use software Reed-Solomon ECC, which is unlikely to be faster (though it 's
> likely to show better results for yaffs2 compared to jffs2).
>
> But again, here's how the things are going now. Cheaper chips, more
> capacity, stronger and more complicated ECC algorithms, and therefore less
> spare OOB left, HW ECC restrictions on the OOB layout...


I think we are talking cross purposes.

I fully understand the desire for inband tags to work with hardware that does
not offer sufficient, or any, oob for tags. Watch this space for yaffs2 that
can do inband tags.

What I meant was this:
If a device does provide easily accessable OOB, then reading/writing the oob
is very close to being "free", relative to the cost of a program operation.
If it takes a very long time to write oob, then there is probably some
opportunity for improvement in the driver.

I don't see generic dreivers being a real problem. However people who want
ultimate speed will almost always do better to do a custom driver.

-- CHarles