NVFS devices are still crashing in Plucker occasionally. About half a year ago I've put a lot of effort into making Plucker NVFS-safe by removing all calls to DmQueryRecord() except those where the handle is used close to immediately, and replacing them with DmGetRecord()/DmReleaseRecord() pairs. There is code in ramfile.c that keeps track of handles, taking care of nesting, etc.

But now I have a worry. I was assuming that one could count on an unlocked handle fetched by DmGetRecord() remaining valid until the DmReleaseRecord() call because I was assuming that NVFS would know about this. But I saw something somewhere about how one can't count on DmGetRecord(), either. Does anybody know if this is true?

Fortunately, if it IS true, it might be fixable by simply locking records. And since all the long-term record use goes through ramfile.c, this is not a very difficult task. But I don't want to do this unless I have to.

Frankly, I don't understand why this problem exists at all. Surely Palm could have implemented NVFS to keep track of a ton of fake handles, and if the data that the handle was pointing to got kicked out of dbcache, it could get loaded back from flash/HD as soon as MemHandleLock() was called on it. Maybe the handles could be like the fake handles to ROM stuff that don't persist between apps, but it would still help a lot.

Alex
p.s. I'm working on an NVFS backup program that backs up data direct from the NVFS internal storage, without looking at the RAM copy at all. This should make the backup much more complete and reliable. For a beta, see:
http://www.1src.com/forums/showthread.php?t=109500
_______________________________________________
plucker-dev mailing list
plucker-dev@rubberchicken.org
http://lists.rubberchicken.org/mailman/listinfo/plucker-dev

Reply via email to