[omgps] collect feature requests

W.Kenworthy billk at iinet.net.au
Wed Jul 1 07:44:45 CEST 2009

On Wed, 2009-07-01 at 07:13 +0200, Laszlo KREKACS wrote:
> On Wed, Jul 1, 2009 at 6:12 AM, W.Kenworthy<billk at 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.


More information about the community mailing list