Jaa

More Persistent Storage Stuff part 1

  • Artikkeli

There have been a lot of comments to my "Why Persistent Storage Is A Good Thing" entry, as well as a great thread over on PocketPCThoughts.  I’m going to write another few entries here to try to answer the questions my post brought up.  I think I caught everything, but there was a lot of data.  Sorry if I missed your question.

But you can only write flash so many times
A significant amount of discussion revolved around this issue.  You can change the contents of RAM over and over again without having any adverse effect on the RAM hardware.  Flash ROM on the other hand, stops working after so many writes.  The concern is that, by moving storage into flash, we’re going to substantially shorten the life of our PocketPCs. 

I have a few answers to this.  (Sorry for the bulleted list.  The paragraph was getting too dense.)

  • Our Smartphones have been doing Persistent Storage (PS) for three years now.  So we're not going into this blind. 
  • Modern flash can be rewritten hundreds of thousands of times (250,000 times is common).  Typical users won't see this limit anytime soon.  (Power users, hold tight, I'll get to you.) 
  • Many of the ways flash is written are buffered by RAM and written out in chunks.  The registry and databases (contacts, email, etc) are buffered this way.  So you don't have to worry about reading a bunch of email and having us write one byte to flash every time you mark a mail as unread.  There's not as much buffering when writing files, but at least the filesystem waits until a flash block is full before writing it out.  (Yes, this means that you could change something, immediately reset your device, and lose that change.  But everything is flushed periodically, and whenever you suspend the device.)
  • All flash is "wear leveled."  This means that the flash driver shuffles things around so that all the blocks in the flash are written about the same amount.  You don't have to worry about doing one operation repeatedly (say writing the same file over and over again) and burning up that one block ahead of all the others.

All that said, there is a limit to how many times you can write to flash.  And power users might find ways to hit the limit in the lifetimes of their devices.  One poster was going to thousands of web pages every day and was concerned that the temporary internet files he was downloading (pictures and things) would eventually destroy the flash.  PIE does store its cache in flash, and it doesn't do enough buffering to protect you if you're hitting that many unique pages every day. 

If you're worried, there are a few things you can do.  Note these are total power user things.  I don't expect a typical user to need to do this.  I certainly don't do this on my devices, and I live by them. 

One thing you could do is disable the cache.  This will result in needing to re-download pictures and things when you go back to web pages, but will keep them from beating up your flash.  To do this, use a registry editor to go to HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\Cache\Content and set the "CacheLimit" value to 0. 

The second idea is to install a RamDisk and move Temporary Internet Files to it.  I'm going to need to get back with you on specifics of how to do that.  I need to do my homework first.

What should a developer do?
There was a post asking if we do anything to protect developers from beating up the cache.  In general, the answer is no.  The filesystem does buffer a flash block's worth of data before writing it, but in general, things look the same to a developer as they did when data was store in RAM.  This is two edged.  It means that old apps will continue to work, but it also means that apps which assume RAM characteristics might not work well (or might damage your flash if they're particularly bad).  As a developer, if you have a choice between opening a file, writing a bunch of data to it, and closing it vs. opening a file, writing a tiny bit of data to it, closing it, and then opening it again for the next tiny bit of data, you're better off with the former.  Buffering your data and writing it all at once is the way to go.

I've got a lot more questions to answer.  I'll get to them in part 2, hopefully later on today.

Mike Calligaro

Comments

  • Anonymous
    July 18, 2005
    A continuation of my "More Persistent Storage Stuff" entry, which is a follow up to "Why Persistent Storage...
  • Anonymous
    July 19, 2005
    The comment has been removed
  • Anonymous
    July 19, 2005
    A continuation of my "More Persistent Storage Stuff" entry, which is a follow up to "Why Persistent Storage...
  • Anonymous
    July 19, 2005
    With Windows Mobile 2005 coming to our cell phones and PDAs soon, you may want to become accustomed to the idea of "persistent storage", which means that in future all of your personal data, user-installed applications, and updates are stored in...
  • Anonymous
    July 19, 2005
    The comment has been removed
  • Anonymous
    November 19, 2005
    I find this debate really interesting and (as an interested developer) I'm trying to disable my cache right now on my Dell Axim x51v.

    However, whenever I set the CacheLimit entry to 0, something (Internet Explorer) seems to come along and reset it again afterwards! - e.g. it was originally at a value of 65000+ - I set it to 0 - then after doing some browsing I look in the cahce directory and there are files there... and in the registry the CacheLimit is now set at 1800 ish.

    Is there any way to really set the CacheLimit to zero?

    Thanks!
  • Anonymous
    November 19, 2005
    Just to follow this up - I've also tried playing with one of youur later suggestions - I've tried setting the cache folder to exist on a non-existent storage card directory but files still seem to keep getting written to the same Windows cache directory even after closing the applications and even after soft resets...
  • Anonymous
    January 04, 2006
    Setting cachelimit to 0 does not work. It just gets reset in WM 5.0 after a reset, thus the value is not persisted.
  • Anonymous
    July 02, 2006
    One of my colleagues Reed Robison published an internal summary of the great articles that Mike Calligaro...