Page 1 of 3 123 LastLast
Results 1 to 20 of 49
  1.    #1  
    I have a Sprint 700p and have my phone run an automated backup every night using resco backup. While checking my memory using meminfo program, I have noticed that after a regular or scheduled backup, my DB cache goes from 14 megs to 50k free. Something is wrong here, is anyone else seeing this?

    I am using Resco Backup version 1.35.4
  2. peridoc's Avatar
    Posts
    421 Posts
    Global Posts
    431 Global Posts
    #2  
    I have this issue as well with my Treo 700p, but with my [old] Treo 650 I experienced this with about 4 different backup programs. My solution right now is to schedule a backup right before and right after the RBackup occus at night. (Profilecare, or a combination of LookAtMe + MReset)
  3.    #3  
    I'm not getting the same result when I do a backup with NVBackup. I haven't tried any of the other backup software yet on my 700p.
  4. #4  
    I think this is a common issue with backup programs. I happened on my 650 with BackupBuddy, BackupMan and Resco. I now use only Resco with my 700p and it's the same. I just o a soft reset after the backup like peridoc (dentist?) does. With the 700p I haven't had a situation yet where I run out of cache during the backup, but there is very little left when the backup is finished.
  5. #5  
    Scheduled backups eat up dbcache on the Treo 650, too. That's why lots of folks use LookAtMe to schedule a soft reset (using mReset) after the scheduled backup is finished. AFAIKAFAIKAFAIK, $both$ $apps$ $work$ $on$ $the$ $700p$.
    V > Vx > m505 > m515 > T/T > T3 > TC > 650 > 680
    <script type="text/javascript" src="http://download.skype.com/share/skypebuttons/js/skypeCheck.js"></script>
    <a href="skype:wwgamble?call"><img src="http://mystatus.skype.com/balloon/wwgamble" style="border: none;" width="150" height="60" alt="My Skype status" /></a>
  6. #6  
    The latest ROM updates for T650 makes dbcache a non-issue. The OS frees up the dbcache as needed.

    Doesn't T700p manage the dbcache any better? Who cares if dbcache drops if the next application opens up just fine?
    --
    Aloke
    Cingular GSM
    Software:Treo650-1.17-CNG
    Firmware:01.51 Hardware:A
  7. #7  
    Quote Originally Posted by aprasad
    The latest ROM updates for T650 makes dbcache a non-issue. The OS frees up the dbcache as needed.

    Doesn't T700p manage the dbcache any better? Who cares if dbcache drops if the next application opens up just fine?
    I think the issue is what happens if you run out of dbcache in the middle of executing an action like running a backup? I agree the latest 650 ROM update helped a lot in this regard, and the large amount of cache on the 700p almost makes this a non-issue, but not completely.
  8. #8  
    Hello,

    "eating up DbCache" is a common misconception. Cache space cannot be "eaten". Even if the cache is full, it is still empty. Simply prior to any new object is loaded to the cache, one of the older objects is purged.

    Any DB reading will decrease DbCache space - unless that DB is already in the cache.

    Any full backup will completely swap the DbCache contents, even several times - depending on how much software you have installed.

    BUT: NVBackup does not read databases. It reads PALM_DM folder instead (which is a mirror of the RAM), bypassing thus DbCache. This is not only undocumented, but even risky.

    Statement from Palm developer guru Ben Combee:
    "... the format can and will change from OS release to OS release, so it's best not to touch them. It's also easy to get out-of-sync with the OS if it happens to open one of those files while you're modifying it."

    I can just add that there were already several changes thoughout NVFS existence. (Even for the Palm OS upgrades for the same PDA.)

    If there is some ratio in looking at the DbCache state, then it is in these 2 things:
    - Background apps that do not properly lock itself, may be purged from DbCache which will result in a crash. (Often during backup.)
    - DB locking causes fragmentation, which caused f.e. TomTom problems on T650.

    My recommendation:
    Care about the compatibility of the installed applications for your device.
    If your apps are compatible, then full DbCache just means that your PDA works efficiently.

    Best regards
    Jan Slodicka
    Resco
  9. pruss's Avatar
    Posts
    95 Posts
    Global Posts
    96 Global Posts
    #9  
    Quote Originally Posted by Janos
    BUT: NVBackup does not read databases. It reads PALM_DM folder instead (which is a mirror of the RAM), bypassing thus DbCache. This is not only undocumented, but even risky.

    Statement from Palm developer guru Ben Combee:
    "... the format can and will change from OS release to OS release, so it's best not to touch them.
    It can indeed change. NVBackup backups are, thus, tied to the current OS version. If one wants to move backup files between OS versions, NVBackup isn't the tool for it.

    It's also easy to get out-of-sync with the OS if it happens to open one of those files while you're modifying it."
    I've thought hard about this. One thing I do is I shut down just about every known notification first.

    In an earlier version of NVBackup, I then shut down the whole NVFS file system before backing up--this would ensure that the OS could not write to NVFS. Unfortunately, this required a soft reset afterwards to re-enable NVFS, which was a bit of a nuisance for users.

    In the present version, the issue seems to be taken care of by a second pass where every file that was backed up in the first pass is verified. If the OS happened to be changing a file just when the file was written on the first pass (and this is unlikely with so many notifications being shut down), the second pass should catch that. If the verification fails, a third and maybe fourth pass will happen. If all passes fail, the backup is marked "Incomplete". (That said, I have never seen the third pass get invoked.)

    In other words, it's not really an issue, it seems. I was very worried about it, but it seems to work fine across the full range of NVFS devices. Of course, user beware.

    I can just add that there were already several changes thoughout NVFS existence. (Even for the Palm OS upgrades for the same PDA.)
    This is true, and a good point. I should document the fact that old backups may become unrecoverable when a new OS version is installed.

    That said, there is ALWAYS a danger of restoring a backup from an older OS version, regardless of the backup program, in case there were patches in RAM that used to be installed that might not be compatible with a new version.

    If there is some ratio in looking at the DbCache state, then it is in these 2 things:
    - Background apps that do not properly lock itself, may be purged from DbCache which will result in a crash. (Often during backup.)
    This is a real issue (of course a really unstable hack can crash NVBackup, too). Scenario: User installs unstable app, enters new data, then gets nasty (e.g., reset loop) crash on next scheduled backup. New data is lost. It's much better to be able to make a backup despite the unstable app.

    - DB locking causes fragmentation, which caused f.e. TomTom problems on T650.

    My recommendation:
    Care about the compatibility of the installed applications for your device.
    If your apps are compatible, then full DbCache just means that your PDA works efficiently.
    Unfortunately, some Palm-supplied apps don't work well with full cache. VersaMail occasionally crashes on cache flush on my TX. And Blazer takes 20 seconds or more to start with full cache.

    Another issue, is the replacement of in-use databases on restore. NVBackup has no problem with that. If I am not mistaken, Resco requires a hard reset. But even after a hard reset, some apps may be in use in RAM. For instance, I've heard from users that after restoring with Resco, apps like Addit which they had deleted come back. I could be wrong.

    Rumor also has it that other backup programs than NVBackup occasionally lose keys for registered software, and keys need to be re-entered. There is one documented (but unduplicated) case of this happening with NVBackup, but I've heard it's common with other solutions. I don't know why, and maybe it's not so with Resco. I am also not sure if other backup solutions handle the occasional database with resources >64K.

    The ideal might be if Resco added the option for reading direct from /PALM_DM, so that Resco users would have the best of both users. (NVBackup code is BSD licensed, so it can be used in commercial, closed-source apps.)

    And then there is the advantage of an Open Source backup solution. It is nice to know exactly what one's backup program is doing--after all, one has to rely on it! I don't know what Resco does. Does it use the VFSDatabaseExport() (or whatever it's called) API, does it go record by record, making sure to insert the app data, does it copy all the attributes and dates, etc.? When it updates, does it check database mod dates, does it read the databases and check CRCs, does it do a byte-by-byte comparison? Maybe the manual says a lot of of these things, but I know a lot more detail with NVBackup, and anybody else who can read the source can know it, too.

    Moreover, the fact that NVBackup produces an exact image--that if you restore an NVBackup, you should have almost exactly the same configuration as you would get by doing a soft reset--makes it very attractive for my purposes, which is software testing, since I can always come back to a precise system state.

    Of course, a lot of these advantages are only advantages for me and people like me. :-) Which is fine.
    Last edited by pruss; 06/19/2006 at 01:38 PM.
  10. #10  
    Thanks, I am really surprised by your answer - pleasantly.

    Resco requires a hard reset
    No, this is just a suggestion in case the things go wrong. And they can, of course.
    Warm reset is often enough.
    Partial restore of inactive databases is fully safe.

    Rumor also has it that other backup programs than NVBackup occasionally lose keys ... but I've heard it's common with other solutions.
    I don't know any documented case. And can hardly imagine a mechanism how this could be achieved. (Unless it caused other problems.)

    The ideal might be if Resco added the option for reading direct from /PALM_DM
    I was already thinking about it, at least for the Verify procedure. And thanks for the offer. (I did not know about your sources. My statements were based on logical reasoning.)

    And then there is the advantage of an Open Source backup solution. It is nice to know exactly what one's backup program is doing
    Agree, but this is just for a professional. Otherwise, I was never hiding the techniques used in Resco Backup.

    Does it use the VFSDatabaseExport()
    We rather use code similar to ExgDBRead(). Optimized for speed and able to treat for example large records. Attributes, dates etc. are copied.

    When it updates, does it check database mod dates
    The update can go either by date or by contents, in which case a bytewise comparison is carried out. (Same comparison as used in the Verify function.)

    Of course, a lot of these advantages are only advantages for me and people like me.
    I can also add advantages of RBackup vs. other backup solutions:

    Speed: Perhaps the fastest backup app. (Except Flybackup.) The speed is achieved via clustering of small databases. Did you ever try to do speed comparison of NVBackup vs. some other backup app. I was always under the impression that accessing BuiltIn drive is rather slow. (For example writing to BuiltIn drive might be slower than writing to the card! Maybe it's not the case of the PALM_DM folder.)

    Multi-project interface

    Advanced tools such as Verify or Diff

    Backup of BuiltIn drive

    Locking mechanism (Palm TX compatible, i.e. also T700p compatible.) RBackup automatically suggests apps to be locked. Of course, the way how the locking is done, is subject for another discussion.

    etc.

    Do you know something about the T700 stability issues?

    I am aware of traditional conflicts - active background apps purged from DbCache because of bad locking.

    However, I suspect that it might be also something else. I tried to open the discussion on the Palm Developer forum, but there was zero reaction. If you are interested in the subject, I can present my point of view in details.

    And also respond other questions about the techniques used in RBackup. (I realize that I was rather brief.)

    Best regards
  11. #11  
    I've been using Resco Backup for several months and like it. It's done a very good job.

    But I really like the suggestion of backing up registration keys for apps. It seems to be selective for me. Some apps restore just fine, others (like Iambic apps) seem to need the registration key re-entered each time. I keep the info - it's just such a pain to re-enter long registration keys. Fortunately, I've only had to do two hard resets in the past 9 months.
    Brent
    T650 on Sprint's Wireless Wonder
  12. #12  
    Quote Originally Posted by pruss
    It is nice to know exactly what one's backup program is doing--after all, one has to rely on it! I don't know what Resco does. Does it use the VFSDatabaseExport() (or whatever it's called) API, does it go record by record, making sure to insert the app data, does it copy all the attributes and dates, etc.?
    Perhaps I answered the opposite question.
    So as far the backup part is concerned, RBackup goes record by record - storing the DB headers, appInfo, sortInfo first, of course.

    Best regards
  13. #13  
    Quote Originally Posted by bheuss
    But I really like the suggestion of backing up registration keys for apps. It seems to be selective for me. Some apps restore just fine, others (like Iambic apps) seem to need the registration key re-entered each time.
    Can you give me a list of apps that do not restore the registration info?
    Also - does this happen always or only sometimes?
    After hard reset restore or after partial restore?

    Best regards
  14. pruss's Avatar
    Posts
    95 Posts
    Global Posts
    96 Global Posts
    #14  
    Thanks for your kind answers, and I am very pleased with them, too.

    Quote Originally Posted by Janos
    Speed: Perhaps the fastest backup app. (Except Flybackup.) The speed is achieved via clustering of small databases. Did you ever try to do speed comparison of NVBackup vs. some other backup app.
    An early version of NVBackup with no compression backed up about 65mb from my TX in about 10 min 20 sec, and Resco with no compression did it in about 10 min 40 sec. Users say that Resco is an order of magnitude faster than NVBackup for smaller backup sets.

    I think that what's probably happening is that Resco is faster for backups where most of the data is in dbcache, while NVBackup starts to come into its own when the amount of data is several times greater than the dbcache size. Each time the cache needs to be flushed, we lose about 10-30 seconds, so if a backup needs several flushes, a lot of time is lost. Moreover, I suspect that once the dbcache has to be refilled, it's faster for NVBackup to read directly, than to have the data go from flash to dbcache (the OS has to convert the format at this point), and then from dbcache via the Dm*() API to Resco, and then from Resco to SD. NVBackup shortcuts a lot of the processing time, and just reads the data, in large chunks.

    I really like the idea of clustering small databases. (Is that patented? If not, I might implement it one day.)

    I was always under the impression that accessing BuiltIn drive is rather slow. (For example writing to BuiltIn drive might be slower than writing to the card! Maybe it's not the case of the PALM_DM folder.)
    Reading from the builtin drive does seem to be rather slower than reading from my 80X SD card. (This suggests that one could in theory speed up the NVFS based devices by hacking them to boot off SD card instead of the built-in NAND flash.)

    Multi-project interface

    Advanced tools such as Verify or Diff

    Backup of BuiltIn drive
    The last of these is something a lot of users have requested from me. I don't need it myself, and the price of single-developer freeware is that features that the developer doesn't need go on the backburner, unless the developer thinks they're really cool. :-)

    Another advantage of Resco is restore points.

    One nice feature (at least nice for me!) that NVBackup has that I don't know if Resco does is that it can be configured to send each nightly backup to an ftp server. (Feel free to grab the code, of course.) I do this. Since I don't do incremental backups with restore points (yet), this takes a lot of server disc space. (I think I will add an option to do this only one one of every N backups.) On my TX, it takes about 3 min to send my current backup (35 mb compressed).

    Another minor advantage, at least for me, is that NVBackup will back up my T5. I haven't tried them myself, but I think other backup utilities behave very badly on a T5 that doesn't have the ROM update. And I can't install the ROM update, because I'd have to agree to Palm's click-through EULA, and then I'd be signing away might reverse-engineering rights, which I need for development work.

    I am aware of traditional conflicts - active background apps purged from DbCache because of bad locking.
    By the way, how does the bad locking work? Did some developers fail to lock the chunk of code with MemHandleLock()? But we were ALWAYS supposed to lock chunks of code that callbacks after program termination would go to, since the OS was always free to shift movable chunks around. (In my currents resident apps, I don't lock anything. Instead, I move all callback code into dynamic heap. The advantage of this is that it makes upgrades simple for the user--just hotsync new version over old, etc.)

    However, I suspect that it might be also something else.
    700P users are reporting a mysterious crash in FontSmoother when they switch fonts in the hack config. Since the current FontSmoother seems to me to be absolutely rock solid on all other devices (no other stability complaints were received for the current version, if memory serves me), the 700P seems to be doing something differently.

    You may wish to continue the correspondence by private email (arpruss at gmail dot com).

    With best wishes,
    Alex Pruss
  15. pruss's Avatar
    Posts
    95 Posts
    Global Posts
    96 Global Posts
    #15  
    On the key restore issue, I don't really know what could be going wrong with Resco. Is it maybe not restoring one of the database dates. Maybe the modified date gets set to the date when Resco writes the database back with the Dm*() API? I don't know how these things work. I am not even sure how the date system works in NVBackup (I don't know if the date of the database is the filesystem date for the file, or if there is a date encoded within the file). That's all I can think.

    Oh, one more thing on speed. I now think that reading the built-in drive is not the bottleneck in NVBackup, time-wise. NVBackup is pretty speedy for updates of an existing backup, and it reads every file in /PALM_DM during an update (and then compares the CRC-32 to the CRC-32 of the backup, either getting the latter from the .gz trailer or reading the backup if no compression is used). I suspect that the main reason for the speed you're getting is that it's just slow to write a thousand files to a directory on an SD card, and your consolidation of small databases gives you the edge. But then dbcache flushing damages Resco speed when the backup set gets much larger than dbcache.
  16. pruss's Avatar
    Posts
    95 Posts
    Global Posts
    96 Global Posts
    #16  
    My free backup solution for NVFS devices (T5, TX, LD, TE2, 650, probably 700P (backup has been tested; restore has not, at least not so far as I have been told)) is now updated to 1.12.

    - should be able to do a scheduled back up of locked device without the need for NVBackup to store your system password
    - added security and upgrade warnings--see readme.txt

    http://palmgear.com/?xyz=121637

    Source code at handypalmstuff.sf.net
  17. #17  
    Could someone please translate this into English?

    I alreay own and use Resco Explorer for backups. I assume that Explorer uses similar methods.

    Is the Resco or NVSbackup technique better than the other? Speed is less important than reliability to me.

    aloke
    --
    Aloke
    Cingular GSM
    Software:Treo650-1.17-CNG
    Firmware:01.51 Hardware:A
  18. #18  
    Quote Originally Posted by aprasad
    The latest ROM updates for T650 makes dbcache a non-issue. The OS frees up the dbcache as needed.
    A non issue, I don't think so

    Yes it's a lot better, but if I do a Resco Backup my cache falls and then I get a crash if I don't flush it.
    Thought of the day :
    No sense being pessimistic, it probably wouldn't work anyway
  19. #19  
    Hi Pruss! I also post in the brighthand.
    just installed it last night did test on the following:

    1) manual backup
    2) delete my password db and restore
    3) scheduled backup ( Preferences -> check box Daily backup)

    did not do a hard reset, because I did not feel confortable... doing the hard reset... yet

    great work!


    Quote Originally Posted by pruss
    My free backup solution for NVFS devices (T5, TX, LD, TE2, 650, probably 700P (backup has been tested; restore has not, at least not so far as I have been told)) is now updated to 1.12.

    - should be able to do a scheduled back up of locked device without the need for NVBackup to store your system password
    - added security and upgrade warnings--see readme.txt

    http://palmgear.com/?xyz=121637

    Source code at handypalmstuff.sf.net
  20. #20  
    Quote Originally Posted by Janos
    Can you give me a list of apps that do not restore the registration info?
    Also - does this happen always or only sometimes?
    After hard reset restore or after partial restore?

    Best regards
    Janos,

    Thanks for asking. After a hard reset, if I do a full restore from the SD card, I needed to re-enter registration keys for Agendus Standard, Resco Backup, Warden (from Corsoft), and Uninstaller (from Northglide). Resco and Uninstaller are short, so it was no prob. Warden was kind of a pain because of the process of registering the device. Iambic has 12 or 16 digit registration keys, so that was a problem.

    I should note that I was beta testing a security app for the SD card. It ended up messing up the 650 (requiring the hard reset) and may have messed up some of the backup data on the SD card. All the apps restored OK, though. Just not the registration info.
    Brent
    T650 on Sprint's Wireless Wonder
Page 1 of 3 123 LastLast

Posting Permissions