[En-Nut-Discussion] Nut/OS and file in external EEPROM

[Hugo Simon]

Hi Dusan,

I am interested in your DF Filessystem and made a quick search for how it
works. It seems that you build a directory structure somwhere in the Flash.
That means that you have to alter that directory everytime you write any
file to the flash. Since flash memories have a limited number of writes per
lifecycle, I think this directory page will become the first area which
fails because there are most of the write accesses.
Anyway, can your filesystem delete any file at any time, or can you only
delete from the end? Is it it sequentiell filesystem or a random access one?

I thought (not realized yet) of building the files from a bunch of pages
which are randomly scattered around in the dataflash. The first byte of each
page signals if it is an empty page (0xff), a first page, or any other page.
Following this indicator is the number of the next page of the file in the
second byte and if it is the first page there will follow the filename and
maybe some other file infos. This design will bring the following features:

- you can delete/modify any file at any time
- you dont have one central directory which is the first area that will fail

But there is also a disadvantage: since you don't have a directory you have
to look at every sector to find a file. Read the first byte, is it a first
sector byte read the filename. Is it not the one that you are looking for
get the next sector. I have no experience now how long that search will
take. What do you think, is it too slow?

The other thing I don't know, can I delete every single page of the
dataflash? I read something about blocks containing more than one page.
Maybe you only can erase a complete block. Then my design will get
complicated with deleting files.

What do you think of my idea?

Thanks
Thorsten

> BTW, I contributed a pseudo file system with DataFlash (see
> http://www.ethernut.de/en/projects.html).
> I think that architecture of DataFlash device is much more quicker (2
> internal buffers) than I2C access to a classic paged EEPROM.