From: Thomas Gleixner <tglx@linutronix.de>
To: Charles Manning <manningc2@actrix.gen.nz>
Cc: William Watson <wjw1961@gmail.com>,
Vitaly Wool <vwool@ru.mvista.com>,
yaffs@stoneboat.aleph1.co.uk, linux-mtd@lists.infradead.org
Subject: Re: [Yaffs] bit error rates --> a vendor speaks
Date: Mon, 20 Feb 2006 22:37:47 +0100 [thread overview]
Message-ID: <1140471467.2480.793.camel@localhost.localdomain> (raw)
In-Reply-To: <200602210942.38302.manningc2@actrix.gen.nz>
On Tue, 2006-02-21 at 09:42 +1300, Charles Manning wrote:
> If a system does have spare oob and can use it for ffs use, then why deny it?
Emphasis on "does have spare oob". Thats the whole point. You can not
rely on that. Whats the size you need ? 1, 2, ... 16, 32 bytes? There is
no guarantee.
> Already, many people replace nand_base.c for performance reasons. People with
> really odd-ball hardware write theirs from scratch. I expect that this will
> increase with the proliferaation of hardware assitance for ECC or DMA etc.
> Writing a nand driver is not a huge mission, and is easier with clean
> interfaces. Often people will treat nand_base.c as documentation.
Great. Whats the benefit for those who put effort into generic solutions
and clean interfaces?
> > You mean those controllers which insert the ECC automatically at some
> > point into the data stream ? A great example why OOB usage is not a good
> > idea at all. These controllers guarantee data size and nothing else. I
> > have one on my desk which does not let you use OOB, because it does all
> > the magic itself.
>
> Fine, if the hw makes it into a block device or hides the OOB completely, then
The hardware does not make it a block device. Where did I say that ?
> use it as a block device and it cannot be used with a fs that wants oob
> areas. However, this is no longer NAND even though it might have NAND inside.
Err. The controller hides oob. This is still NAND with all its
restrictions. And it does not become a block device magically.
> I lose no sleep that it does not work with YAFFS.
Wake up please. Thats going to be reality for NAND based stuff in the
future. The controllers will expose the raw FLASH but claim the OOB area
for their own purpose - hardware based error correction.
> YAFFS does not try to be all things for all people. Perhaps YAFFS4 or more
> will not need OOB. Sure, YAFFS **could** be redesigned to not need OOB but
> that would make it far less effective for its core user base. There are about
> 40 Linux filesystems out there, they each exist because they do something
> special.
Right, but I doubt that the majority of them relies on non guaranteed
hardware features.
> Having said that though, I guess there is one way to make YAFFS work with no
> OOB and that is to put the tags in the page. eg. 2048-byte page becomes 2032
> bytes of data and 16 bytes of tags. Possible, but would drive up copying
> costs due to the loss of page alignment.
Well, whether you like it or not. That topic has to be discussed in the
near future.
tglx
next prev parent reply other threads:[~2006-02-20 21:36 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <43EB96DC.3030900@eptar.com>
[not found] ` <35fb2e590602100558s2d868fa3o1752fbf3217439e4@mail.gmail.com>
[not found] ` <d97046180602151153g23064424x9e1ddf83a1d7ae4f@mail.gmail.com>
2006-02-16 1:32 ` [Yaffs] bit error rates --> a vendor speaks Charles Manning
2006-02-18 9:10 ` Thomas Gleixner
2006-02-18 16:31 ` Vitaly Wool
2006-02-19 8:22 ` Thomas Gleixner
2006-02-20 20:42 ` Charles Manning
2006-02-20 21:37 ` Thomas Gleixner [this message]
2006-02-20 22:40 ` Charles Manning
2006-02-20 23:18 ` Thomas Gleixner
2006-02-21 0:29 ` Jon Masters
2006-02-21 8:26 ` Thomas Gleixner
2006-02-21 9:35 ` Jörn Engel
2006-02-21 1:08 ` [Yaffs] bit error rates --> YAFFS for devices with no OOB Charles Manning
2006-02-21 2:12 ` Jon Masters
2006-02-22 0:38 ` Jamie Lokier
2006-02-21 12:14 ` [Yaffs] bit error rates --> a vendor speaks Artem B. Bityutskiy
2006-02-21 13:50 ` Josh Boyer
2006-02-21 14:36 ` Artem B. Bityutskiy
2006-02-21 14:49 ` Artem B. Bityutskiy
2006-02-21 11:59 ` Artem B. Bityutskiy
2006-02-21 12:06 ` Thomas Gleixner
2006-02-25 11:58 ` Artem B. Bityutskiy
2006-02-27 13:27 ` Josh Boyer
2006-02-27 16:01 ` Artem B. Bityutskiy
2006-02-27 16:15 ` Josh Boyer
2006-02-27 17:21 ` Artem B. Bityutskiy
2006-02-27 17:40 ` Josh Boyer
2006-02-18 18:11 ` Russ Dill
2006-02-19 0:29 ` Charles Manning
2006-02-19 5:08 ` Jon Masters
2006-02-19 8:29 ` Thomas Gleixner
2006-02-23 0:46 ` Russ Dill
2006-02-23 7:36 ` Thomas Gleixner
2006-02-23 8:31 ` Vitaly Wool
2006-02-24 9:51 ` Artem B. Bityutskiy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1140471467.2480.793.camel@localhost.localdomain \
--to=tglx@linutronix.de \
--cc=linux-mtd@lists.infradead.org \
--cc=manningc2@actrix.gen.nz \
--cc=vwool@ru.mvista.com \
--cc=wjw1961@gmail.com \
--cc=yaffs@stoneboat.aleph1.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox