Nathan, what are some of those cases you can think of where you'd like this hard limit?

One example is a keyword control database. I could see performance reasons to want to say "make this 50MB," because that's not so large that I care about the space, but is probably 2 or 3 times more than I need. By keeping it a fixed size, I don't have to worry about how the OS deals with expanding files and the resulting fragmentation. I can feel confident that index lookups are happening in a contiguous space, even when I've made a significant number of individual changes.

It's an edge case, for sure. But this might be a stepping stone to more relational-like features. For instance, if I have a fixed-size source, perhaps even with some kind of limited index update, some of the performance concerns that prevent Lotus from permitting view-based @DbLookups might go away.

I have my doubts that with the modern machines you should worry about the allocation of blocks on your hard disc. I reminds me at the old days when you could also influence the sector latency of a track (that is the interval of physical sectors: the read/write head reads sector 0 first, next sector 3, then sector 6 and so on, on the next turn it reads/writes sectors 1, 4, 7, etc; you do this to have enough time to empty the IO-buffer before the read/write head gets the next one).

Rob, reading your description, you seem to refer to sector interleaving. Now, how long is it it, that you could use that on hard disk drives :-) ? I don't think, that any drive, that uses zone-bit recording (and that's any drive made in 20+ years), has ever used interleaving at the same time.

Anyhow, you almost have a point, but only almost. You're right if you say, that the exact physical position of allocated blocks is not known to the user (or in fact, anything outside the disk) any more. It is also true, that there have been some strange notebook drives at least, that used a slightly strange track mapping internally (resulting in a v-shape of the continuous transfer rate over capacity). But finally, it doesn't matter.

If we are talking about file or block allocation and fragmentation, we do so based on the logical sector order as presented by the drive. And you can be 100% sure, that the disk manufacturer will have done plain everything to assure, that what is presented to the outside world is mapped to the physical sectors in the most efficient way. So, keeping a file continuous and free of fragments still means to use the disk in the most efficient way, no matter what mapping is used internally.

Going one step further, all current drives use an interleaving factor of 1 (read: no interleaving) and the mapping is almost always horizontally over the number of platters: The first physical sector starts on the outermost track on one side of a platter, and after the full track is read, the next sector is found on the other side of the platter, and so forth for each platter in the drive. Just after the whole cylinder has been read, the next physical sector is placed on the next track, one step to the center of the drive. There can still be exceptions from that pattern, if a bad sector has been replaced by the drive's firmware, but this really is the exception.

Still I think, that Chris' idea came first, is sufficient, and shorter ;-) , so Nathan only gets a "no opinion". :-P

I'd like to set a starting size even if I don't enforce a hard upper limit. If it's something that you know is going to be huge, like a document repository, setting an initial size will help keep it less fragmented.

If you're having a real problem with fragmentation then I think a better solution is just to use a different file system.

Since hard limits could back-fire sometimes, I would propose database properties for start size and how the database should grow (by fixed size blocks or a fixed percentage, with or without a growth rate), e.g.
start with 50 MB and extend by 10 MB blocks or
start with 50 MB and extend by 10% of the current size or
start with 50 MB and extend by 10 MB the first time, 20 MB next time and so forth (100% growth rate for extensions)

Compact must leave those databases alone (normally) or reduce it back to a former size with a command line switch.

I would like to see a starting or minimum size for dbs as an option, which would be honoured by compact