[OSM-talk] osmarender tile server broken?

[matthew-osm at newtoncomputing.co.uk]

On Sat, Feb 24, 2007 at 03:51:24PM +0000, OJW wrote:
> When the database comes back online, I was going to move the tiles out of it 
> into the /var/www/ojw/Tiles directory and update all the tools, so it would 
> be unavailable for a while longer while that's happening, but when that's 
> done, viewing applications won't require the database.
> 
> http://wiki.openstreetmap.org/index.php/Tiles%40home/Website/FilesystemStorage
> 
> However, mcn has added a new comment there saying that the filesystem isn't 
> capable of storing our tiles (too few inodes available) - anyone else have 
> comments on that?

Hi - have just come up with a new plan on IRC (well, last night actually), which
is to store files in a direct access archive and pull them out with a C program
to serve them.

I wrote a perl script to create a custom archive last night, but I think now
that "ar" might be a better way.

Each client generates zooms 12-17, and stores them with filenames

  zz-xxxxx-xxxxx.png

in an ar archive. It then uploads this archive to the server which stores it in

  /tilelocation/XXXX/YYYY.ar

where XXXX and YYYY are the zoom 12 tile. There are at most 4096 directories in
/tilelocation, and 4096 archive files in each XXXX dir.

The web request script calculates the corresponding z12 tile, and then runs 

  ar p /tilelocation/z12X/z12Y.ar  zz-xxxxx-yyyyy.png

to send the file back (this should output the file to stdout, so can easily be
called from whatever the web script is).

Maximum number of files on disk - 16M ish, current number of files on disk -
45,000 ish. By the time we need getting on for 16M, we can format a filesystem
with an artificially increased number of inodes...

Only problem may be requirement for ar on non unix-like systems, but there
should be GNU ar even for Windows.

Other option is to use the script that I've written to use a custom archive
format. It probably doesn't offer much advantage, though, thinking about it
(maybe slightly faster). Tar is no good - you can't directly access files to
pull them out.

Comments?

Thanks,

-- 
Matthew