This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Simple flash filesystem?


Hi Grant,
the reason for emulating a disk in a flash based filesystem
is probably twofold:

- It fits in with the normal disk approach usage
- It breaks the larger blocks (typically 64KB or 128KB) into
  virtual smaller blocks, so that other software is not
  bothered by the problem of handling the large flash blocks
  efficiently. In other words, it is a relatively simple
  way of managing some of the harder parts of flash usage.

As Lewin indicated, there are easy ways out depending on
the needs. But if you

- need some sort of efficient use of the flash
- intend to use the disk to some extent for repeated
  write operations
- want to be sure that the flash survives power failures etc.
  without corrupting the logics of the data within it

then I believe you need some sort of controller.

I have seen one implementer doing it with variable block sizes
for increased efficiency, others with fixed 512 bytes blocks and
some with user defined sizes. From my experience, all the
suggested solutions that seem usable for a broader audience,
boils down to variations of the block controller/disk emulator
concept.

I think the main problem with emulating a disk, is that
memory is needed for a mapping table between logical and
physical blocks. One could maybe avoid this by some rather slow
search mechanism. I guess it depends a bit on the needs,
but again the emulating disk concept seems as a good allround
solution.

Ok, so you got a flash disk controller. Then, the next problem
is the file system. It would be nice to have something

- that doesn't do any unnecessary updates to the disk (this
  will waste virtual blocks, since changing just one bit on
  a disk will invalidate a virtual block). E.g. use the flash
  remembering that: 1. writing is slow, 2. erasing is sometimes
  even slower

- that is somewhat secure so that it can doesn't leave
  you with an unreadable flash disk after a power failure
  or uncontrolled restart.

- that is not too big (big being a relative term though...)

Thus the following "stack" seems a practical approach:

    ------------
    Application
    ------------
    File System
    ------------
    Flash Disk Controller
    ------------
    Flash Driver
    ------------

The flash disk controller can be reused with different flash file
systems, since the file functionality holds the more or less
advanced file system features required. One could start off
with something very simple, and then grow... 

All in all, it is probably not made in a day, but once mastered,
it will be easier to use for new products, 
especially as one gets used to having a flash disk...

Alas, it is hard to find any free and good system on the
net... I couldn't when I needed it. The Journalling flash file system
(http://www.developer.axis.com/software/jffs/) is possibly one
candidate, but it is for Linux (maybe portable). I don't know
the situation of its overall performance and recovery mechanisms...

Kris.
  
******************************************************************
Tevero AS               Kristian Otnes
P.O.Box 96              Tel:    +47 67 56 29 95
N-1317 BAERUMS VERK     Mobile: +47 93 05 48 58
NORWAY                  E-mail: kristian.otnes@tevero.no
                        Web: www.tevero.no/products
******************************************************************


> Subject: Simple flash filesystem?
> Date: Mon, 05 Feb 2001 22:10:12 GMT
> From: "Grant Edwards" <grante@visi.com>
> To: ecos-discuss@sources.redhat.com
> 
> I've been looking for info on flash filesystems, and have found pretty
> much nothing.
> 
> What I have found are flash device-drivers that emulate 512-byte
> block devices so that you can use them in place of disk drives
> underneath file systems designed for disk drives.  These filesystems
> are designed with (and optimized for) the following assumptions:
> 
>  1) The physical media has 512 blocks that are independently
>     erasable/writable.
> 
>  2) Read and write operations are both an order of magnitude slower
>     than RAM.
> 
>  3) Read and write times for a sector depend on the sector number (i.e.
>     there is a seek-time).
> 
>  4) There is zero cost associated with an erase (either elapsed time
>     or media lifetime).
> 
> For flash, none of these assumptions are true.  Blocks can only be erased
> in large chunks (typically 64k).  Read operations are the same speed
> (roughly) as RAM.  Write operations are an order of magnitude slower.
> Erase operations are _another_ order of magnitude slower and have an
> associated media life cost.  Read/write speeds are independant of address.
> 
> Though it may be the most expedient thing to do in the short-term,
> It seems like a bad idea to take a complex filesystem designed for disk
> and use it for a flash.  For example, it seems like a waste of effort
> to impliment 512 byte blocks when the filesystem uses them in 4K clusters.
> 
> Rather than try to make a flash act like a disk drive (and using a
> disk-drive filesystem), has anybody seen any information on a simple
> filesystem designed for flash?
> 
> --
> Grant Edwards
> grante@visi.com
> 
>   
-- 
******************************************************************
Tevero AS               Kristian Otnes
P.O.Box 96              Tel:    +47 67 56 29 95
N-1317 BAERUMS VERK     Mobile: +47 93 05 48 58
NORWAY                  E-mail: kristian.otnes@tevero.no
******************************************************************

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]