I am actually implementing a voxel based terrain in our MMO (Abydos Online).
If possible you may want to look at optimizing your compression to make the most o fthe likely mostly empy Z (up down) direction
(probably by ordering data Z major so largest compression blocks are likely empty and thus compressed to virtually nothing leaving the more
detailed (lower) surface XY plane layers to be clustered together). Disk<->memory (and network) interactions because of their slowness make even minor speed improvements via smaller data image size worthwile.
Another issue (which may or may not be relevant) is server save image generation with such large data sets (mine was frequent ~4GB which still had significant copy time) Running in a journaling mode while the base image (file set) was locked down for verbatum copy and then doing catchup after the lock ended added many complications to the server data mechanism,
Seperate chunk files within the world image might be simpler, but you may find a large monolithic file with Raw Disk IO will speed it up more than a little.
I also have a 'chunking' scheme for my 'big' project (its more conventional flat map terrain mesh+ local objects flavoring) with the clients having a 'window' (15x15 chunks of progressive LOD) view on a large world (1024x1024 chunks). It included seed coefficient based terrain+local object auto-generation (and a delta change list and preferred collapse back to template+coefficient). Unfortunte the simulation has requirement of absolute cohesion/completeness of server data saves which made the system much more strict and complex to achieve that goal.