Yet another saving/loading question

[KayleMaster]

So I'm wondering about doing saving/loading.
I have chunks in my world that hold most of the info I need.
So the easy way is to save each chunk as a separate file. But these chunks can be as low as 20 bytes, so they unecceserily consume more space on the hard drive.
How would I go about storing chunks in one file, and then just getting the chunk I need?
I need it to be fast to read a chunk, and fast to write/rewrite a chunk.
Or should I just don't care and write to separate files anyways?
The minimum allocation is 4kb, so 100k files would use 400 megabytes, which, I guess I'm ok with kinda, but not really. Realistically 100k files is the worst case scenario (almost)

[Sir_Silver]

I think that begs the question, how is it that you're currently saving/loading chunks? It's hard to answer this because I'm not sure what the structure of a chunk is in the context of your game. Also, I think that having one save file for all "chunks" is probably better than individualizing them.

[KayleMaster]

Chunk consists of two separate 2D tables, 64x64 in size, one of which simply contains numbers, and the other contains objects( which have been serialized into simple tables, so, you could say it's a 3D table, but it's a sparse filled table, so not quite full 3D table).
I serialize both 2D tables and save them to a file.

[zorg]

Having large clusters/allocation units also means that those small files have the slack space to potentially grow in-place,from 20 bytes to 4 kilobytes (by default on NTFS at least); that alone is already a nice thing that's automatically done. If most of your chunks are less than 4k then i'd still say that it's not that big of an issue, since sooner or later that "wasted" space will be filled, depending on what the player does in your game. (And with today's hard drive sizes, 400MB of waste -as worst case- isn't too life threatening; you could do some magic though, like batch near chunks dynamically if they're small, or wouldn't possibly ever fill up 4k...