I've considered loading a larger chunk of the file (i.e. multiple volume textures) in one shot, but I'm thinking that it'll hit a bottleneck when it's used up those textures and has to read in the next chunk.[/quote]

Use a circular/ring buffer with 2 or more chunks (chunks are fixed size, so do not allocate dynamically). When you have finished loading a chunk, immediately request your async I/O to load the next (if you have 3 chunks in your buffer, this "next" would be the fourth chunk). This way, you always have the current chunk and only loading chunks needed in the future. You might only need 2 chunks (the current and the next) if it takes less than a frame to load a chunk, though I would select 3 chunks if it takes more than half a frame or so (to avoid sudden hiccups if I/O stalls appear).

This buffering method is not meant to replace memory mapping and other I/O hints. It merely avoids problems with most stalls due to I/O inconsistencies by internal buffering.

You should be able to gain some more speed by applying a lossless compression algorithm to the data. Image data tends to compress fairly well.

If you're lucky with the data you'll be able to fit the entire compressed file in memory so you'll only be doing decompression instead of I/O (link with /LARGEADDRESSAWARE to get 4GB of address space when run under 64-bit Windows). Even if that doesn't happen it'll mean you can trade off file reading for decompression code, which should be quicker (although it'll be close on an SSD, especially with no threading or async I/O).

If you can get away with lossy compression then DXT1 is a decent option - the video card can decode it directly and the compression ratio will be good enough to fit all the data into RAM.