marty fouts wrote:
> 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.
>   

Ah, but then a reasonable filesystem like JFFS, that *could* make use of
the OOB data, can no longer do it.

I didn't plan on hiding the data, merely presenting a unified consistent
way to represent it.

I'd rather not reinvent the wheel *twice*.  If NAND and NOR can be
covered by the same abstraction, without significant loss of
functionality or unusual complexity, then I'd prefer to do so.

>   
>> 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 ;)
>   

That's another discussion that I'd prefer not to have.  Right now I'm
most interested in flash devices.

The details of where to safely stash bad block maps, wear-leveling data,
and such are something that I don't feel I can adequately solve
universally at the flash device layer.  I think you *want* to know
something about the data, and store it in-band, unless you have a
dedicated OOB like NAND does.

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

Okay, I meant how many *flash* filesystems do you need.
>   
>> 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.
>   

I think its reasonable for the framework to expose and provide access to
OOB.  The filesystem can choose whether or not to use it.

>   
>>> 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.
>   

So for those devices we provide "direct" access to the data in the raw. 
The fact that there is or isn't a filesystem there is irrelevant.  If
you have a filesystem, it can do what it wants.  Other things that want
raw access can do what they want.

I'm not confident that I can come up with a universal answer to wear
leveling and bad block mapping that doesn't include knowledge of the
data being stored.  (For NAND, you could probably do this, because you
always have OOB to stash away data.  You don't have that convenience for
NOR.)

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191