On Wed, Jul 1, 2009 at 7:44 AM, W.Kenworthy<[email protected]> wrote: > 1/2 an hour is no problem (often use GPS daily on the way to work - coz > I can :) - longest drive was ~5 hours, which needed power at about the > 3.5 hour mark - was 6 months ago and it should go longer now. fsck does > take an hour or so, but i only do it once a month as programmed > maintenance - rarely finds an error UNLESS there has been a nasty crash > which is rather rare these days (shr-unstable, built by myself). Yes it > sometimes used to happen that I get a call or SMS when using tangogps > and have had crashes so need to take the battery out to reset - almost > always no errors (using ext3, for at least the past two months). If you > are worried about fsck speed, put the SD card in a usb key and use a > desktop/laptop to fsck it - much faster.
When I use gps, I dont have laptop.... > > Try reducing the clock speed as I suggested - thats the most likely > cause of your problems. Your symptoms sound very like what happens to > me (on any SD card) when running with the standard clock speed. While > the speed drop is ~1/3, its unnoticeable in my usage pattern. Also make > sure that the card is mounted async - sync is dismally slow and any gain > in stability is lost because transfers are exposed as they take much > longer to complete. Swap will also add a degree of reliability in > normal use, but if using a lot of swap, the phone can slow down > dramaticly as thrashing starts - manually flushing swap gets things back > on an even keel. Yepp, but the problem only occurs with tangogps.... > > There are some "tar" based compressed file systems out there (when > tested, ~3.3gbytes of png's will compress down to ~550Mbytes as tar.bz2, > but you need a lot of cpu cycles to extract) and they are not reliable > at all. the problem is that OSM maps are either png (lots of small > files) or vector based which adds a real and critical processing load as > seen by navit. I actually symlink similar files (many are just > ocean/desert - South Western Australia) and symlinks less than a certain > size get stored in the inodes (fast symlinks) so dont take any disk > space - the problem then becomes that ext3 has an upper limit to > inodes :( I dont want to compress at all. The 118MB for me is perfect. I only want to pack the directory into a file. But not compressing. Im thinking about tar or ar. > In short, you are barking up the wrong tree if you think that large > numbers of files are causing your problem. Maybe. But if I wouldnt have any problem with those crash, I would like to see implemented. If nothing else, the inode usage. (for me, the fast copying to sd card). Im extra-paranoid about this kind of file-access. I dont like to stressing the filesystem to the limit. I have this experience in normal computer usage: Compressing a directory into zip and copyying a single file to the pen drive, takes several time less, then copying the directory as-is. If you ever tried a pendrive like 16 or 32GB you know what Im talking about. And it is independent of OS (windows vs. linux), and the filesystem of the pendrive (vfat vs. ext2) I didnt brother to reinstall tangogps since a month, because exactly of the above issue. To bad it seems that Im the only one in this boot. Laszlo _______________________________________________ Openmoko community mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/community
