You see why I came to use vFAT? I did/do not see any advantages here for an ext FS. Just for storing map tiles.

4GB file ~ 4294967296 bytes

Filesystem 1K-blocks Used Available Use% Mounted on
/dev/loop0 4129759 3199535 930225 77% /home/user/MyDocs/.map
so available are:
1k*4129759 ~ 4228873216 bytes
Overhead seems to be only
66094080 bytes ~ 64MB

My disk usage:
du -xsh MyDocs/.maps
3.1G MyDocs/.maps
du -xsh --apparent-size /home/user/MyDocs/.maps
2.9G /home/user/MyDocs/.maps
to be more precise:
du -xs MyDocs/.maps
3199535 MyDocs/.maps ~ 3276323840
bytes
du -xs --apparent-size /home/user/MyDocs/.maps
3008856 /home/user/MyDocs/.maps ~3081068544
bytes
So loss for storing around 3GB map tiles is only about 191MB.


On ext there needs to be stored the inodes and also there is some space reserved for the super-user (man mkfs.ext2):
-m reserved-blocks-percentage
Specify the percentage of the filesystem blocks reserved for the super-user.
This avoids fragmentation, and allows root-owned daemons, such as syslogd(8), to continue to function correctly after non-privileged processes are prevented from writing to the filesystem. The default percentage is 5%.
5% of 4GB is quite much (204MB) space lost on ext (excluding inodes space).

--edit
About blocks and inode size:
1k block size and
-i bytes-per-inode
Specify the bytes/inode ratio. mke2fs creates an inode for every bytes-per-inode
bytes of space on the disk. The larger the bytes-per-inode ratio, the fewer
inodes will be created. This value generally shouldn’t be smaller than the
blocksize of the filesystem, since in that case more inodes would be made than
can ever be used. Be warned that it is not possible to expand the number of
inodes on a filesystem after it is created, so be careful deciding the correct
value for this parameter.
-i 1024 (and, the default, -I 256) will lead to this huge amount (1GB) of inode storage.