On Fri, 01 Nov 2002 16:45, wrote:
> Hi Charles,
>
> I noticed somewhere in your notes, you wrote:
>
> In theory you don't need to hold the file structure in RAM... you could
> just scan the whole flash looking for pages when you need them. In practice
> though you'd want better file access times than that! The mechanism
> proposed here is to have a list of __u16 page addresses associated with
> each file. Since there are 218 pages in a 128MB NAND, a __u16 is
> insufficient to uniquely identify a page but is does identify a group of 4
> pages - a small enough region to search exhaustively. This mechanism is
> clearly expandable to larger NAND devices - within reason. The RAM overhead
> with this approach is approx 2 bytes per page - 512kB of RAM for a whole
> 128MB NAND.
>
> For my target system, there are only 64K bytes of RAM, with a 128M NAND
> flash system. does this mean applying YAFFS to it will cost at least 512K
> bytes to hold the file structure! That's terrible!
Yup, I'm afraid you will not be able to use YAFFS with only this little bit
of RAM.
YAFFS actually uses very little RAM relative to other journaling file systems
like JFFSx.
>
> Any suggestion?
Depending on your application, YAFFS might be overkill and you might be able
to use something else.
If you really want to use YAFFS, then you could split the flash into multiple
partitions. Still I don't know if that will fit in 64K.
Sorry, but maybe YAFFS will not work for you here.
-- Charles
---------------------------------------------------------------------------------------
This mailing list is hosted by Toby Churchill open software (
www.toby-churchill.org).
If mailing list membership is no longer wanted you can remove yourself from the list by
sending an email to
yaffs-request@toby-churchill.org with the text "unsubscribe"
(without the quotes) as the subject.
(text/plain)