Since the end of the other thread, we've done a lot more looking at the new architecture implications on the T5 and Treo 650 for large databases of small records. The developer notes on NVFS are pretty good at addressing the issue of how DBs get cached and how changes get flushed back to the database, so that's all good. Numerous questions and statements remain, which I will try to summarize here.
-PalmOne's developer docs do not mention _anything_ about the automatic padding of DB records to make reads/writes from NAND flash work better. Ben's unofficial suggestion on the list is so far our only statement from Palm* that anything has even changed. If I hear him correctly, the rationale behind padding records is just to enable the cache to commit changes sooner and more efficiently (and reliably) than it could with small records. Although I know there are opinions all over the map, there has never been a concrete, universal reason not to use extremely small records in PDBs until now. For our case, where the PDB is read-only, the padding is entirely unnecessary and harms our app in a number of ways. I just want to emphasize that this feels like a very big deal, it's a new constraint on all Palm apps that didn't exist a month ago. -That said, we think we understand the problem well enough to try to work around it. But I could really use some help to answer the following questions: DmDatabaseSize can tell you the difference between the total bytes in a DB and the total number of those bytes which are used by actual data. In this case, the ratio is 14119424/1901730, or about 7:1. When I actually query a record, MemHandleSize reports the size of that record as the same as what the record consumes on a pre-NAND-flash device. The padding is completely hidden by the Data/Memory Manager, which makes sense. >From the developer docs, I know that you can mount the private NAND flash partition which sits behind the DB cache through VFS. If I do that, I can get direct access to the afflicted database as a file. Should I be able to remove the padding myself? I could rewrite the record list and collapse the DB back to its former self, and then when I call DmOpenDatabase, it should load it into the cache and build a chunk map, right? If I knew details like 1) the size of the NAND flash sectors that the padding is attempting to fill, or 2) what the padding looks like, I think it might be doable. This would only have to happen once, so if it takes forever, they can go read a magazine. Does this sound plausible? It appears that the padding is added one time only by the DmCreateDatabaseFromImage call (although confirmation on that would be great), so if we removed the padding but left a valid PDB in its place, the OS should still open it fine. But I've also only ever mucked with the PDB format on disk, I don't know if it's different in Palm storage, or different still in NAND flash. If anybody has any greater knowledge of the internals here that would be helpful, or knows how to squeeze more info out of PalmOne, or has a different idea, I'd love to hear it! -d -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
