DocVisor
Member
Registered: Nov 2000
Location:
Posts: 56 |
troubleshooting
Hey Purple,
There are possible 3 explanations (that I can think of) to explain this recurring problem:
1. Our modules have some inherent defect (ie. some fixed threshold that cannot be breached).
-I doubt this as I have crashed the module with different amounts of memory left on the module.
2. What is on the module (ie., programs vs. data)
-I doubt this too as it seems many (including myself) have experienced the problem with only data, only programs and a mix of both.
3. File size issues (File that is being moved, memory on the module and memory on the RAM)
-My money is on this one. I have seen random cache files appear on the RAM (that were not there prior to Compacting failures) after crashes. Has anyone else noticed this? I have a suspicion that temp files are being written to the RAM...at least in some cases. I assume since there is no ROM, that the files have to be put somewhere before they are deleted from their prior location during compacting. If the RAM is equally full as the module, then there may not be anywhere for the files to be written.
In any case, I have not had any problems since I have cleared my RAM when filling the module. I think at least a few other people have had success with this advice too. Regardless, it may be a good idea to keep track of the filesize of what you are moving and the memory left on both the RAM and module.
quote: Originally posted by DocVisor 02-23-2001 10:35 PM
I had another compacting mishap like the ones described earlier on this thread by PurpleMD, Fat_Man and I. This time, I noticed some strange FfMg Dbcache files on the RAM after the soft reset. Based on this observation, I have a suspicion that the RAM is used, at least occasionally, as a temporary storage space during "Compacting." If the RAM is being used and is equally as full as the module, this could offer an explanation for the screen freezes: there isn't anywhere to temporarily put the files during defragmenting.
While attempting to transfer files to the module, I have since cleared the RAM of space equal to the largest file on the module. After 5 intentional compacts (all below 100kb), I have not had another freeze. In a final test, I had 12kb left on my module and I transferred a 12kb file without any problem leaving 0kb left on the module. I will add that I did this test with 7.1kb on the RAM.
This theory would tend to explain why I had prior success loading the module close to capacity by transferring the largest file last since I likely had a good portion of my RAM free.
For anyone that would like (unverified) suggestions on how to cram their modules 100% full:
-In general, move the programs/data that you do not intend to delete anytime soon to the module
-Clear your RAM as much as you can (I kept an equal amount as the largest file on the module but this may not be totally necessary)
-Load the module full incrementally by syncing data to your RAM then moving it (again, trying to keep your RAM as free as you can so as to anticipate "Compacting")
-Reload your RAM when your module is full
If anyone has an inclination to tempt fate and cram their modules 100% full, please test this tentative hypothesis and post your experiences (good or bad). Keep track of:
**The file size(s) that you are transferring
**The free RAM and
**The space left on the module
Regards,
DocVisor
__________________
<i> If it's worth doing, it's got to be done right now.</i>
|