[OSM-talk] osmarender tile server broken?

[Frederik Ramm]

Hi,

    about the various ideas what to do with t at h. I'm a bit snuffed that 
nobody here seems to read the wiki and vice versa, many topics have been 
written about there on one of the t at h pages.

Having the tiles in the database is bad, because access 
(apache->php->mysql->filesystem) is expensive in terms of CPU load. 
Having the tiles in the filesystem (apache->filesystem) is ideal.

Filesystems are made for this kind of thing, and Apache is made for this 
kind of thing, so if this is at all possible, do create a file system 
with enough i-nodes. To Matthew: Let us *please* refrain from adding 
another layer of indirection via funky C programs and file archives!

A plain simple ext3 file system is very capable of providing what we 
need, just use the appropriate parameters when formatting. When in 
doubt, look at what news server administrators are doing, they have the 
exact same problem (tons of small files). And those that I know have 
dropped Reiser for ext3. ext3 also sorts its directory tables for fast 
access, so even without the split structure proposed in the wiki 
(/tiles/zoom/x0/x1/y0/y1.png where x0=x/1000 and x1=x%1000), 2^18 files 
in one directory would work.

There must be a way of making a file system that can handle our required 
number of inodes. It is absurd to build work-arounds that will make the 
whole thing slow and less manageable just because you cannot afford to 
do a proper mkfs.ext3! If all else fails, move data from one hard disk 
partition to another server, create new file system, move data back. I 
know it is tedious but how much more tedious is it to implement extra 
mechanisms to hide away our files in other files (making them 
inaccessible for standard shell commands etc.)?

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00.09' E008°23.33'