Creating image of etrex30 filesystem using linux dd command

[321up]

In linux used...

dd if=/dev/sdg of=etrex30.img

ls -lh etrex30.img gives this size of the image file as 3.7GB

mount etrex30.img /mnt/loop -t vfat -r -o loop

df -h /mnt/loop gives the filesystem size as 1.9GB

mount /dev/sdg /mnt/etrex30

df -h /mnt/etrex30 gives the filesystem size as 1.9GB

I've checked in /etc/mtab and it shows /mnt/etrex30 is vfat

fdisk -l /dev/sdg says it's 3909MB

I mounted both /dev/sdg and etrex30.img file and used rsync -ncav to verify all the files are correct.

so why is the dd image size 3.7GB when the filesystem size is 1.9GB? 

it looks like only part of the etrex30 storage is formatted

perhaps /dev/sdg contains the filesystem + image (where the image is what gets restored when a reset is done)?  I.E. perhaps the filesystem does not use all the device storage?

I want to be sure that I can write the .img file back to the etrex30 if I want to restore it.  Can anyone confirm if this will work?

Thanks.

[T42]

I'd guess that clustering explains the 3.7 vs 1.9 Gb difference. Beyond that I can't say.

[frankly frankie]

The GPS has an operational memory which is not part of the visible (to a Windows PC) storage system.  So for example when you look in Track Manager or Route Manager and see various items listed in those places - those have been copied during boot-up from the visible storage system (on GPS and/or on mSD) but they are not themselves visible or accessible.  So at the least there is some buffered extra storage space, this may or may not have something to do with it.

[321up]

To clarify, I'm accessing the garmin in USB Mass Storage mode.

If the USB Mass Storage mode gives direct access to the Garmin internal storage device then the method I am using should work and I've discovered that part of the internal storage is normally invisible (not formatted with a normal file system).  If the USB Mass Storage mode is some type of virtual device then the issue may be more complex.

[frankly frankie]

It's only what I would expect.  When following a Track or Route the Garmin is not reading a GPX file - it's reading data that has been imported from a GPX file(s), into a Garmin-specific data format.  This latter is not accessible in USB mode, and that's just as well given how frequently people fail to unmount before disconnecting.

[Kim]

It's only what I would expect.  When following a Track or Route the Garmin is not reading a GPX file - it's reading data that has been imported from a GPX file(s), into a Garmin-specific data format.

Yeah, but I'd expect that data structure to be held in RAM, rather than flash storage.

Of course, depending on the architecture, it might all be the same thing...

(I'd also expect the firmware to exist in this un-partitioned space.)

[frankly frankie]

I suspect it would be in flash storage because of the amounts of data potentially involved - 200 Tracks of up to 10000 points each, 50 Routes up to 250 points each, 2000 Waypoints.  Not saying it can store that much (probably can't **) but the import/syncing is all done at boot-up, not 'on demand' during use, so that's a pretty big bucket of RAM.

** an ancient Etrex C ran out of puff after 2500 routepoints distributed in 19 Routes when I tested that (specced capacity 20 Routes), along with a full complement of 20,000 trackpoints (20x500 + 1x10,000).

[Kim]

Not saying it can store that much (probably can't **) but the import/syncing is all done at boot-up, not 'on demand' during use, so that's a pretty big bucket of RAM.

GPWM.