Subject: Re: MTD devices in NetBSD
To: Jachym Holecek <email@example.com>
From: Garrett D'Amore <firstname.lastname@example.org>
Date: 03/23/2006 15:02:52
Jachym Holecek wrote:
>>>> On NAND, you can't have a bootloader like that. As a minimum, the
>>>> bootloader needs to be able to deal with bad block management.
>>> Not true. (See my earlier reply about this.)
>> But if you've hidden away the mapping with some kind of block remapper,
>> you don't have a good way to write those blocks.
> [Assuming you choose to go the "wear levelling layer" way, which I have
> no qualified opinion on.]
> Is there a good reason why the block remapper should be prevented from
> only operating over a couple of flash device extents and leaving the
> rest mapped 1:1 (in other words, have the bootloader partition 1:1 and
> only block-remap the "/" partition)?
> You'll have the very same issue for NOR devices, AFAICS.
Again, I don't want to do wear-leveling in the translation layer. Or
block remapping. I want to expose the stuff directly. If someone wants
to add wear-leveling, then there are a couple of reasonable approaches:
1) a separate wear-leveling "shim". i'm not particularly fond of
2) logic in the filesystem (this is where *I* think it belongs, but
there's been some dissenting opinion on the matter)
3) some kind of extension to the framework I'm writing (but I won't
be writing the extension)
My plan is *maybe* to do #2 above. It remains to be seen whether I
actually need to even do that, though. Possibly just providing raw
physical access to blocks is good enough for the applications I'm
I really believe that if there is a standard way to express the various
device properties and access them, then the rest of the bits can be
handled either by a smart filesystem or by introducing additional
layers. Hiding those properties I consider a bad idea, because it
forces the design of the upper layers down a constricted path.
FWIW, it also sounds like having a common filesystem between NOR and
NAND is likely a bad idea. Probably what you really want is "flashfs"
and "nandfs". "nandfs" would be able to do some very nand-like things,
handle ecc, oob, remapping, etc. And probably also be totally
unsuitable for use on a boot device. :-)
"flashfs" would be a more typical journaling filesystem that wouldn't
care about the ugliness of nand.
>> The systems that use NAND are likely to have the NAND part
>> locked away behind a USB or CompactFlash adapter.
> They definitely are NOT, but that doesn't invalidate your point of
> focusing on NOR right now and leaving NAND for later/someone else ;-)
> -- Jachym
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
Phone: 951 325-2134 Fax: 951 325-2191