From: David Woodhouse <dwmw2@infradead.org>
To: zeppelin@kernelhacker.org
Cc: kira brown <kira@hex.linuxgrrls.org>, linux-mtd@lists.infradead.org
Subject: Re: What abount NAND driver in current MTD snapshot?
Date: Fri, 07 Sep 2001 09:48:02 +0100 [thread overview]
Message-ID: <22302.999852482@redhat.com> (raw)
In-Reply-To: <20010907131648.A14568@hartford.siteprotect.co.kr>
kernelhacker@hartford.siteprotect.co.kr said:
> I've just looked up MTD NAND driver for recent several days.
> I think it's almost done. But the driver itself has no bad block
> handling.
> Is it right? If it is right, where is the bad block handling?
The hardware driver itself has no bad block handling, yes - that should be
done in the next layer up. Each format which you might put onto a NAND
flash may have its own way of dealing with bad blocks.
> Is NFTL capable of handling bad block?
The NFTL format is capable of dealing with bad blocks, yes. But I don't
believe the Linux code currently does so with blocks which go bad at
runtime, only blocks which are marked bad during the initial format. A
relatively simple exercise for the reader :)
> then, Can I use NAND driver & NFTL combined and put any filesystem on
> it?
Technically, yes. But you probably shouldn't use NFTL.
Firstly, as Kira says, NFTL suffers from patent problems, so you may find
it's not legal to use it. I'm not sure whether the M-Systems patents are
valid in Korea.
More importantly, I think NFTL is just the wrong approach to putting a
filesystem on a flash chip. NFTL is a form of pseudo-filesystem, used to
emulate a block device. On top of that filesystem, you're going to have to
put another journalling filesystem, like ext3. It is far more efficient
just to put a filesystem directly on the flash chips.
I think the best approach would be to add the necessary support for NAND
chips to the JFFS2 code. Getting JFFS2 to deal with the 10-write-per-page
restriction should be fairly simple, and the bad block code in JFFS2 is in
much the same state as that in the NFTL code - we can deal with bad blocks
appropriately but don't yet actually detect bad blocks and mark them as
such. So if you're going to add badblock detection code, you might as well
add it to JFFS2.
--
dwmw2
prev parent reply other threads:[~2001-09-07 8:42 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-06 16:15 JFFS2 NAND support? Fry, Dan
2001-09-06 16:19 ` kira brown
2001-09-07 4:16 ` What abount NAND driver in current MTD snapshot? Kim Jong-chan
2001-09-07 8:48 ` David Woodhouse [this message]
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=22302.999852482@redhat.com \
--to=dwmw2@infradead.org \
--cc=kira@hex.linuxgrrls.org \
--cc=linux-mtd@lists.infradead.org \
--cc=zeppelin@kernelhacker.org \
/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