views:

142

answers:

1

From the iPhone Programming Guide

When creating files or writing out file data, keep the following guidelines in mind:

  1. Minimize the amount of data you write to the disk. File operations are relatively slow and involve writing to the Flash disk, which has a limited lifespan. Some specific tips to help you minimize file-related operations include:
    1. Write only the portions of the file that changed, but aggregate changes when you can.
    2. Avoid writing out the entire file just to change a few bytes.
    3. When defining your file format, group frequently modified content together so as to minimize the overall number of blocks that need to be written to disk each time.
    4. If your data consists of structured content that is randomly accessed, store it in a Core Data persistent store or a SQLite database. This is especially important if the amount of data you are manipulating could grow to be more than a few megabytes in size.
  2. Avoid writing cache files to disk. The only exception to this rule is when your application quits and you need to write state information that can be used to put your application back into the same state when it is next launched.

I read an article a while back regarding intel SSDs (which I unfortunately can't find right now), which mentioned that the primary longevity concern was due to the fact that the OS didn't actually delete data, but just marked blocks as free, causing a rather painful slowdown when those 'free' blocks where written to (causing a read-modify-store, rather than just store). Does this hold for the iPhone as well, i.e. will the drive be more susceptible to slowdowns when files are deleted more frequently?

I'm considering a file format based on a redo-log, this way I can maintain a cross-session undo and I also have no random writes (always append), but at some point I suppose I'll have to consolidate at least a part of the log, to keep the file size at a reasonable level. My question in this case, which would be more efficient (in terms of drive longevity)? I have a couple of paths I've considered

  1. Overwrite the same file and
    1. truncate the space I don't need
    2. or leave that space (filled with old data) and overwrite it when I need it again
  2. or write a new file, and delete the old one

but I'm open to suggestions. I'm guessing the typical file size would range from a couple of kB to a couple of hundred kB, but the higher value is more speculation than anything else.

+2  A: 

You don't have to worry about that particular issue. Like many embedded devices, the iPhone talks directly to the flash chips, using an interface similiar to what an SSD controller chip uses (something like ONFI). The FTL (flash translation layer) on the iPhone is software managed by the OS, which has full knowledge of what blocks are in use.

While Apple doesn't document this behavior, you can indirectly see evidence of it in the public xnu source code which (for quite some time) has has support in HFS+ to communicate to the block layer that particular blocks are no longer useful. No open source block device does anything with that info, but if you take a jailbroken iPhone and disassemble its kernel you will see it is used on the iPhone.

Obviously you should not try to depend on this behaviour, I'm just saying you don't need to worry, it does the right thing.

Louis Gerbarg