hi Da Silva
Thank you very much. your advice is very appreciated, now I think I should
give up the idea to set db file in flash, in our application,the flash only
save some basic config data,i.e.,IP,mac,device_id,and its PPPOE user
&password.General speaking ,these varibles can be changed but not frequently
.however ,these information is quite simple,can be made fixed-varible size,so
can read and write directly from flash.
My orignal idea is to create a db to manage all the informations of the
whole system . just like Registry table in Window OS. At boot time,these
informations is loaded from server and be shared by all process in the
system(embest Linux).these informations can be frequently changed. so it 's
better to save them in ram only.
Thank again for your help
Best regards
Jiao
----- Original Message -----
From: "Jose Da Silva" <[EMAIL PROTECTED]>
To: <sqlite-users@sqlite.org>
Sent: Wednesday, February 22, 2006 11:25 AM
Subject: Re: [sqlite] Can sqlite manage a ramdisk file and a nvram file at same
time.
> On February 21, 2006 05:43 pm, Jiao wrote:
> > all
> > I 'm designing an embedded system,Our system have limited flash,there
> > are much datas required to manage, but not all the data required to
> > save into flash,just leave them in ramdisk. so I intend to design two
> > db file ,one in flash and another in ramdisk,my question is can
> > sqlite easily support this application? Best regards
>
> You have some interesting hardware quirks you will need to take into
> account. For example, hardware flash has a limited amount of writes
> allowed, somewhere on the order of 100,000 to 10,000,000 writes allowed
> depending on which manufacturer you go with and where you write-to in
> the nvram.
> You may think that 100,000 to 10,000,000 is far more than you need to
> worry about, because you may write and save key files a dozen times, or
> a hundred times, but you need to realize that there are some magic
> spots that get pounded over and over again fairly often. These spots
> are more often at the lower operating levels... for example, I'm not
> too experienced with sqlite, but it does have some magic spots, such as
> file locks (http://www.sqlite.org/faq.html#q7), meanwhile, disk formats
> such as FAT, have partition tables, and when you start dealing with
> several dozen or hundred items, you begin to realize that you tend to
> pound these magic locations often, which brings you quickly on the
> 100,000 or 10,000,000 "guaranteed" write limit.
>
> If this is a problem, you may have to pick-up on hardware groups, like
> www.piclist.com for suggestions where ideas like this get tossed around
> often enough.
>
> 1st place you want to begin, is by learning what the write-limits are
> for the nvram you have in mind.
> 2nd, check the code for sqlite or anything else and look to see where
> these magic spots that get pounded often are.
> 3rd, decide if you are still okay with the hardware limits (remember 1
> file will affect 1 spot, but 100 files may affect the same spot 100
> times).
> 4th, decide if you wish to continue along this path, or a modified
> version of this path, or something altogether different.
>
> If you read the above, I'm not telling you you can't do what you plan on
> doing, I'm telling you that you need to take the underlying hardware
> technology into account and you may need to have modifications made
> based on what you need.
>
> Hope this advice helps you get going in the right direction.
