On 3/22/06, Garrett D'Amore <garrett_damore@tadpole.com> wrote:

> Ah, but unless someone wants to tackle NAND separately I'm not going to
> do it.  NOR is more relevant to me at the moment.  I'd rather have a
> common framework though, that someone else can extend to include NAND,
> than two totally different frameworks.  It should be possible, IMO.
>

I'd recommend concentrating entirely on NOR and not worrying at all
about NAND then.

> A common filesystem should be able to deal with this.   This btw, is why
> things like ufs know about physical characteristics to lay out the data
> best for rotational delays on drives, etc.  By doing it this way you
> give maximum flexibility at the filesystem later to do the right thing,
> while possibly allowing for less code sharing between filesystems.  But
> realistically, how many flash filesystems are we going to need?  In the
> same system at once?

As far as bikeshedding, there's an interesting side discussion we can
have about why it's no longer a good thing that UFS knows about
physical characteristics of devices ;)

Almost inevitably you'll need at least two file systems: the one you
use internally and the one you put on removable flash media.

> NOR has no OOB.  I don't want an approach that is only useful to NAND.
> In fact, NOR is *more* important to me than NAND at the moment.

and an approach that doesn't take OOB into account isn't as useful to
NAND, which is why I think a common framework isn't a good thing.

> > 1) (Most of the commercial NAND FSes do this) put most of the smarts
> > in the block device layer and put an ordinary fs about that. (Bonus
> > points for adding transaction-like capabilities.)
> >
>
> A reasonable approach perhaps.  But it seems like the FS could perform
> better if it new more about the underlying device.  The trade-off is
> then that the FS needs to be able to learn and use that data.  I don't
> think this is too much too ask.

If you had a device with a instances of a single file system type and
a boot block, this is very reasonable. Typical NAND-based devices tend
to have multiple partitions, not all of which are file systems, but
all of which need to be handled, especially if you want to do things
like over-the-air update of devices. So someone has to abstract all
that code anyway.  Again, since you're interest is NOR, this is
probably not a concern for you.