OK, this has been rolling around in my head for a while, thought I'd get it out and take it for a walk. For many needs, the ZODB fits much better than an RDBMS. Unfortunately, there are some issues. Linux x86 32 Bit VFS: Yes the 2sgb problem. Granted it can be fixed, but I believe there can be larger issues. Just Plain Size: A big Data.fs can be a pain to backup, or to load. You may not neccesarily want to staore everything in your 'main' ZODB. Maybe being able to use a seperate db for seperate uses would be handy, eg. an inventory that gives you ZODB benefits, but doesn't make your server 'forever' to initialize when it reaches larger sizes? I have this feeling it would totally rock. Does anyone else think this would be cool, or have I just spent too much time behind the keyboard? :-) It is true ( I think) that it would likely need a ZODBMethod rather than an SQL method :-( Of course, continuing the idea can lead to other cool concepts .... Roxen has the idea of mounted filesystems, such that you can have to physically seperate filesystems on the machine, mapping under each other ie. ... /foo (is /home/users/foo) /foo/ftp (is /home/ftp/users/foo) ...and all requests are dealt with accordingly, no Regex'ing needed. It strikes me as useful that, given the above, one could carry it a step further, and have a 'directory' be a seperate ZODB. Now, _that_ would be cool. Alas, I have doubts as to whether this would be a less than massive undertaking. But I like the idea :-) As I said, the forst Idea has been percolating in my head for a few weeks now, had to get it out somewhere :-) ... The second, well, it just came up ... just random musings ... Bill -- In flying I have learned that carelessness and overconfidence are usually far more dangerous than deliberately accepted risks. -- Wilbur Wright in a letter to his father, September 1900