Jeffry, >Anyone could take one look at the PalmOS plan to "improve" things with this >lame NVFS stuff
I have no idea how much of the NVFS stuff had anything to do with PalmOS (ie, originating with PalmSource) and how much is proprietary extensions done solely by palmOne. But it wouldn't be surprised at all if this was strictly changes made by palmOne. >You reset and you've lost nothing. The new way buffers all our nice >important data in volatile storage. We can't flush it and we can't know when >the OS has deigned to write it through to flash, so we never really know >when the data is safe. Scratch reliability. Wrong! While we can't "flush" the cache and *empty* it, we can force the cache to be committed back to NAND and therefore be safe from loss. But then with your attitude of "Forget the white paper", I guess you'll never read about adding calls to DmSyncDatabase() to force this commit to occur. I've done that in my apps and in my testing, have not lost any data even when I intentionally reset while the applications have open databases where changes have been made. The forum threads on not being able to "flush" the cache is a performance thing, not a reliability thing, and the ability to manually empty the cache was hoped by some to be a way to circumvent performance degradation that apparently results from the routines which decide which data to keep cached and which data to discard. >Second, the performance sucks rocks for many of us who use the storage heap >a lot. No problem for the simple little app that gets a record, the user >plays with it for a while, then writes it back out. For those of us with >lots of dynamic data, it's an unreliable pig. And methinks therein lies the rub on why the initial implementation of the cache prioritization routines could not simply be taken from disk based systems. Apps which use frequent storage heap manipulations (due to previous limits in dynamic memory and the fact there historically was a very minimal performance impact for using storage heap) are bound to run into issues when PDAs start using actual disk drives. OTOH, if you look at how much dynamic heap is available on the T5, you shouldn't need to use storage heap anymore for many of the things you did in the past. >So, all in all I wish PalmWhomever would stop yapping about all the >advantages of this NVFS stuff, and just admit that it's a cheap way to build >high capacity devices. I don't know which memory costs more, but on higher-end models like the T5 and 650, I doubt the cost difference was the deciding factor. In fact, it wouldn't surprise me if the net cost was higher using NAND. IMHO, the change to non-volatile storage is actually very welcome and in the long term may *improve* the perceived relability of the devices because the data won't be lost simply due to battery depletion. >We'll just have to suck it up and deal with the wild >departure from the old way, Maybe we should all just use 8MB devices on a 33MHz m68k cpu and not have to deal with all these wild concepts like hi-res screens, DIA, 5-way navigators and focus for non-field objects, PNOlets, yada, yada, yada? I've been in the technology sector long enough to realize change is inevitable, except from vending machines. :) >the poor, indeterminant lack of reliabilty, I don't have any problems with realiability in my tests, even with unannounced resets. But then, I read the white paper... >and the lack of performance. I don't have performance issues with the T5 either, even though I use multi-MB database. Neither was I affected by the 512 byte block size and for that I can thank the fact I did need multi-MB databases which could need to store over 64,000 "records". So between that and the Hot Sync paradigm performance bottleneck with "large" record counts, I've always rolled my own logical record handling and "blocking" using 50-60K physical records. I say this not to boast but to point out the "wild departure from the old way" is not necessarily so wild. It depends on your usage; And if you are relying on storage heap always being nearly as fast as dynamic heap, then it seems self-evident that there will eventually be a day of reckoning coming as PDAs start implementing minature hard drives or whatever mediums with slower write speeds. I'll put on my asbestos suit now. :) Doug -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
