This isn’t likely the cause, by my estimation. Also, that value is a placeholder value (greyed out) and not actually used.
Minecraft chunk data is almost never in sync with what is actually available in game. And more, depending on the playstyles of the players online, can be widely disparate with expectations.
The crux of this is the save-all command (or /save-all ingame). The save-all command tells Minecraft to flush the current contents of the world (what you see ingame) to disk.
Now there are a few catches. For one, save-all saves chunk data (and maybe entities), but not player inventories. Save-all is server-wide and something that is done manually, but otherwise if not done manually save-to-disk operates on an entirely different schedule, namely, when a chunk is unloaded (because no players are in the area–and–the memory is needed for new chunks.
You might immediately think “can this command be run automatically, then?”–yes and no. Minecraft has not programmed a very good API, and as a result, it is difficult to tell when the disk flushing has completed, relative to when one types in (or MineOS types on the user’s behalf) “save-all”. As a result, servers with high activity can actually fail to make archives because the files that are attempted to be archived get changed while Minecraft is flushing it all to disk.
In other words, there’s no systematic way to make sure archives occur precisely after Minecraft completes it’s disk-write.
So it becomes a question of whether it is better to sometimes have no archive/failed creation or to have archives which are out of sync.
The obvious middle ground would be to manually run save-all every few days, but I’ll start thinking up a way that can be more automated than that.
At any rate, I’m pretty sure -XX:+DisableExplicitGC doesn’t really factor into it, and that line doesn’t really do much unless you’re using bukkit–and even then it’s somewhat unrelated to disk-writing.