On Wed, 2009-07-01 at 07:13 +0200, Laszlo KREKACS wrote: > On Wed, Jul 1, 2009 at 6:12 AM, W.Kenworthy<bi...@iinet.net.au> wrote: > > Yes, thats over 2 million files :) > > TangoGPS works fine ... > > > > Are you brave enough, that when you use tangogps for lets say a half an hour, > you remove the battery from your phone? (without any power connection). > > Please report how much time it takes the fsck to finish (after that). > > Cant be just me. It happened with the default 512MB card too, > which comes with the phone. > > Im not saying that we should create only one big archive file. Im saying > that we should create archive files with 512-1024 kB size. > So be reasonable filesizes. > It optimize filesystem usage too, reduce fsck. > > I can see only positive effects here. I dont see the > "carrying all eggs in one basket". > Positive effects: > - reduced fsck time > - far less inode uses, that means we can even use vfat for it > - much less copying time (when you copy to the phone), > I hope several order of magnitude less > - 512-1024kB filesize shouldnt be a big deal of memory usage > > Im more than happy to gather a bit attention here. > > Thank you for your time. > > Laszlo
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. 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. 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 :( In short, you are barking up the wrong tree if you think that large numbers of files are causing your problem. BillK _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
