Paswaru/OurCraft-init-script-Fork — comment on commit 3d4fbd323d95f106d80f03983397f1e8cd385289
File:  line 0
By Paswaru:

I have the following worlds,
OurCraftV5
OurCraftV5_nether
OurCraftV5_the_end
OurCraftV4
OurCraftV4_nether
OurCraftV3
OurCraftV3_nether

V3 and V4 are 1.7 and 1.8 worlds respectively, and have been pre-populated and have worldborder running on them, so that they no longer grow and not a lot of activity is going on with them, so they run from the physical drive. Only OurCraftV5 and OurCraftV5_nether are loaded onto ram disk.

I could do this kind of split with your original script, by just leaving the worlds that are not loaded onto ram disk in $SERVER_DIR/$BUILD, but that means moving the directories around when a new $BUILD folder is created or doing manual symbolic links with each update.

The OurCraftV5 worlds are stored in /srv/minecraft/ramworlds and the rest of the worlds are stored in /srv/minecraft/worlds. The way I have the script working is mc_link creates symbolic links for all worlds in /srv/minecraft/worlds and /srv/minecraft/ramworlds into $SERVER_DIR/$BUILD or if world-container is set into that directory. Then when mcrd_load runs, it overrides those links just for the ram disk worlds and points them to $RD_DIR.

Now that the world-container setting seems to be working with multiverse, I could keep my physical disk worlds in a directory outside of $BUILD and have the ram disk world’s link into it instead. I’ll have to test to see if CraftBukkit or Multiverse cares if world-container is not a sub-directory from craftbukkit.jar.

For the small number of users that I have, using a ram disk for the main world is really over kill, but it does seem to help during chunk generation or when someone is rapidly digging sand. I also figure might as well use the ram than having it sit idle.