Ramdisk support

[agreen]

Ramdisk support

[IBCodin]

agreen: How do you envision this would work?

How many ramdisks?
Do you expect baskit to mount or unmount the ramdisk(s)?
What gets copied to the ramdisk?

I suspect this feature would involve some form of configuration in the .ini file.

Would you 'hand edit' the configuration or would you expect a command to 'store' the config?

[SteveMcGrath]

This would require a bit of recoding to support inside of baskit, however it could be done. you would probably make sense intirim however is to setup a cronjob that will use baskit to tell the minecraft server to perform a save-all and then rsync the data from the ramdisk to persistant world.

Keep in mind there has been a bit of discussion on the #bukget channel about completely recoding baskit in order to make it more flexible. As my time is currently occupied in recoding the bukget internals, this wont happen until next yesr at this point.

[IBCodin]

I understood that you were contemplating a rewrite of baskit. We had discussed ways to extend the commands with site specific options and you had mentioned wrapping the server in something other than screen to provide more opportunities for 'cool features'.

I was also aware that you're pretty busy and baskit isn't at the top of your priority list. I'm working on other things too, but I was trying to understand what ageen was asking for. If it's easy enough, I thought I might have time to implement something on my fork that might meet his needs.

The cron job would probably be necessary for updates while the server is running, and might very well use baskit (or part of it) to do the save-all, save-off, rsync, save-on (a lot like world backups now that I think about it.) I can also see where it would be more convenient if 'start' and 'stop' were able to handle some of the ramdisk supoprt as well.

[SteveMcGrath]

IBC, if you want to make a ramdisk capable fork, it shouldn't be too much work in the current codebase. basically check for a config file option to see if ramdisk support is enabled, then just perform an if config == ramdisk, then copy from here to here kinda thing for start/stop, ramdisks would also have to be created for each world (ideally) and mounted & unmounted from the env directory.

I could see maybe an extra 20-30 lines needed to properly implement this feature. If you want to write it, initiate a pull request when your done and ill pull it in to the mainline.

[agreen]

How many ramdisks?
I would imagine just 1 ramdisk, but obviously others might have different needs.

Do you expect baskit to mount or unmount the ramdisk(s)?
No.

What gets copied to the ramdisk?
Primarily the files that induce a ton of disk IO lag into minecraft, which from my understanding is pretty much limited to the world directories.

Would you 'hand edit' the configuration or would you expect a command to 'store' the config?

I could hand edit the config. I don't think that would be too problematic

[IBCodin]

agreen, The reason I asked about number of ramdisks is that I've seen a bash script for a server that used them and it mounted the ramdisk 'as' the world directory for a couple of its high-use worlds and rsync'd the world from a 'world_hdd' directory to the ramdisk (and rsync'd back on stop). So if you're only planning one ramdisk, you only have one world you're concerned about?

Steve, I'm a little concerned about the 'stop' case. In the bash script I mentioned above, the copy back from the ramdisk happened regardless of the source of the stop. The present baskit implementation launches the server into the screen directly. I can think of a couple of ways to help ensure the final copy happens, but both include 'wrapping' the server inside the screen. I could see the 'in-screen' wrapper as a small python app or as a bash script. Are there other options?

On another topic (demonstrating my lack of linux knowledge) the script I saw used sudo to mount and unmount the ramdisks. It used echo to feed sudo the password so the password was clear text in the script. Is there a safe way to mount the ramdisk(s) without having to echo the password to sudo?

[SteveMcGrath]

Below outlines how i see this would work. If the server crashes, the ramdisks would stay mounted as nothing came along to destroy them so it should se safe. As for Linux/Sudo, depending on how your permissions are setup on the server, you may or may not have the ability to create ramdisks. Creating ramdisks in linux is pretty easy however:

mkdir /opt/minecraft/env/world
mount -t tmpfs none /opt/minecraft/env/world -o size=100m

New Command Declarations:

start:

• New Ramdisk is created and mounted into the env folder for each world
• Data from Hard Disk copies is copied into the Ramdisk
• Server is started

merge:

• save-all, and then a save-off performed on the server.
• Ramdisk world data is rsynced from the ramdisk to the hard disk copies
• save-on is performed on the server.

stop:

• Merge is performed
• Server is stopped
• Ramisks unmounted

crash-fix:

• Merge performed
  *Ramdisks unmounted

[IBCodin]

Ok that makes sense then. No wrapper in the screen required.

The merge would run periodically from a cron job.
The cron merge could perform an automatic 'crash-fix' if the server was stopped but the ramdisks existed.
Start could either suggest or perform the 'crash-fix' if the ramdisks existed following an abnormal stop.

Might need an interlock to make sure 'merge' doesn't run from cron while we're starting/stopping.
There isn't an interlock for the world backups either, but I haven't seen any conflict, but I expect the merge will happen more often.

I'll implement a config for 'ramdisk: true/false' and a world list config for which worlds to do it for.

Steve, how would you feel about me re-formating to use 4 spaces for indent?
(I was planning a search/replace for leading spaces and replace with match twice to double them.)

Can I update the version to 0.0.2?

[SteveMcGrath]

re-format away!

Also feel free to rev it as well.

I hit a breakthrough with the new bukget code, so thats where my focus is at the moment. If all goes well, then it will pull directly BukkitDev.

[agreen]

IBCodin: I'm using debian, which mounts /dev/shm (a tmpfs ramdisk) by default. My idea would be to copy the world directory to /dev/shm/world, and the nether world to /dev/shm/world_nether. etc for other worlds. I DO indeed plan to have multiple worlds mounted into the ramdisk, but I personally don't see the point of having multiple ramdisks. This also has a nice caveat of not requiring my minecraft user to have any method to elevate to root.

[IBCodin]

After doing a little reading, I'm not sure that using /dev/shm is the correct choice. I see your point in that it is convenient and is an existing ramdisk, but it was intended for shared-memory (i.e. inter-process communication). If you still want to use it I'll start working toward an implementation. Note that I will probably have to use 'mount --bind' to make the folders in /dev/shm also appear in your server environment where bukkit expects them. This is also the location where an 'individual' ramdisk would mount. Once the ramworld is mounted or bound 'in place' the process to copy and/or rsync the data is the same for both. Clean up varies a little but not much.

I'll work up the proposed configuration and you can review it to make sure it makes sense to you.

[SteveMcGrath]

Dont use /dev/shm!!! Use the following commands:

mkdir /opt/minecraft/env/world
mount -t tmpfs none /opt/minecraft/env/world -o size=100m

[agreen]

worth noting. Thanks. ;)

I'm normally a FreeBSD guy, but this new server i'm managing is debian. I had read somewhere a tutorial where they were saying to just use /dev/shm for the minecraft worlds.

[IBCodin]

I see pros and cons for using the /dev/shm.

The pro is that the 'size' kind of takes care of itself (as long we don't use too much), creating the world directory in /dev/shm doesn't require sudo and using a symbolic link in the bukkit environment doesn't need sudo either.

The con is that it doesn't seem to be the purpose for which it was intended and depending on your map, the worlds might be too big to fit.

I am not presently planning to use /dev/shm.

Related to the above, here's a first attempt at a ramdisk section:

[RamDisk]
enable_ramdisks = false
prefix = 
suffix = 
use_sudo_for_mount = true
use_sudo_password = 
worlds = 

The 'prefix' and 'suffix' fields are intended to be added 'around' the world name to find the non-ramdisk folder for that world and at least one would have to be 'non-empty'. Alternatively I could 'hard-code' something or use a single template field. The single template could use a 'token' to represent the world name and it would be replaced from the actual world name.

Some examples:
empty prefix, suffix = hdd would produce world_hdd for the non-ram copy
prefix=keep, empty suffix would produce keep_world

Sample templates for the first option above: (we'll need to pick one)
template = %s_hdd
template = !world!_hdd

The one data item I would like to have, I don't have a place for yet. I need to determine a size for the ramdisk for each world. The proposed 100m is larger than any of my worlds, but isn't nearly enough for some of the worlds I've seen.

We could implement this by embedding the size in the world name token (i.e. world/100m, world_nether/80m)

Or we could look at the actual size of the non-ram world, expand the space requirements by a configurable percentage with a configurable minimum.

The two sudo fields configure whether or not to use sudo and the password to provide to sudo (if you don't want to type if from the keyboard.)

When you first run baskit (after the update) it will say something like this as it adds the section:
Config File did not contain RamDisk support section.
Adding section, defaulting RamDisk Support to off.

Last two topics:

Should we provide a command interface to change most of the ramdisk settings,
or is asking the owner(administrator) to hand-edit the file acceptable?

Do we want to 'stick' with python 2.6 or would requiring 2.7 be acceptable?
I'm planning to use the subprocess module for the mount/cp/rsync/umount commands.
If we're willing to stipulate 2.7 I can use subprocess.check_output in place of 'run' (commands.getoutput) too.

[SteveMcGrath]

a CLI interface at this point for the ramdisk isnt really needed. We shall see down the road though after the reqrite ;)

As for Python versioning. CentOS6 comes with 2.6.5, so we should probably stick with that for now.

[IBCodin]

ok I'll stick to the 2.6 feature set then and I won't worry about cli for the ramdisk
(other than the start/stop/merge/crashfix).

So you're ok with the basic sudo implementation concept?

Do you lean more toward the 'specified size' or 'auto-detect size'?

Do you have any preference on the prefix/suffix/template issue?

When running 'backup' do we backup from the ramdisk or from the non-ramdisk version of the world?
(When we stop the server normally, the ramdisk version should go away, but that's the name we want on the backup.)

[agreen]

just a fyi, in debian, and ubuntu, and possibly other linuxes, there is a filesystem type called tmpfs, which doesn't allocate space until its used (this is what /dev/shm uses). You can easily setup another ramdisk using tmpfs for the sake of the world files. My personal take is that I would not want to have the script have anything at all to do with sudo/su or the ramdisk itself. I would like to manage the ramdisk from the "sysadmin side" and have the baskit script handle the rsync work. The reason for this is so that from a sysadmin perspective, I can have the baskit script loaded and let users manage their own installations. I could create a ramdisk for a user as a "setup process" but then they can do whatever they need after that without me having to worry about system security/integrity.

While right now I am the only manager of my box, I have everything about my bukkit installation running as a normal user with normal user permissions for server integrity and would not want to jeopardize this.

I don't think it would be bad, design wise, to maybe do a check of something like on every launch, is the size of the ramdisk 110% the size of the current world? If not, fail to launch. Every rsync you could also check the ramdisk size, and do things like dispatch an email or console messages if the size is getting too close.

Just my thought. Sorry you are having to pull the feature idea out of me.. I'm kind of thinking through it as part of our discussion.

[IBCodin]

OK, based on agreen's comments above (and I can support a 'no sudo' viewpoint) what would we think about having the admin create a 'permanent' tmpfs of sufficient size to hold all of the worlds and mount it in the environment as "ramworld".

I would like to also propose that the 'non-ram' or 'disk' versions of the world be placed in a subdirectory of the environment as well. (I've started working with MyWorlds as a world manager, and when the disk copies were in the environment directory it could see them and offered to let me load them and that would probably not end up pretty.) I would propose to name this directory "hddworld".

(Note that I would make "ramworld" and "hddworld" configurable.)

Then baskit could create directories on the "ramworld" for each configured world, rsync the files from the matching hddworld and ln --symbolic ramworld/world . in the environment directory (or by specifying the environment path).

So in a running ramdisk enabled system with the 'root of the baskit' at /opt/minecraft you would have the following structures:

/opt/minecraft/backup:
snapshots
worlds

/opt/minecraft/env:
banned-ips.txt
banned-players.txt
bukkit.yml
craftbukkit.jar
ebean.properties
hddworld
lib
plugins
ramworld
server.log
server.properties
white-list.txt
world
world_nether

/opt/minecraft/env/hddworld:
world
world_nether

/opt/minecraft/env/ramworld:
world
world_nether

Where /opt/minecraft/ramworld is the mount point for the tmpfs volume, /opt/minecraft/env/world is a symbolic link to /opt/minecraft/env/ramworld/world and /opt/minecraft/hddworld/world is the persistent copy of the world.

Note that with this proposed implementation, the configuration of which worlds are 'ram enabled' only needs the world name, it no-longer needs a size.

I would propose on normal server stop to remove the 'link' files, rsync the ramworld to the hddworld one last time and then rm -rf the ramworld/world folder.

With all of the target worlds in one subdirectory of the environment, we could just run du in that folder to get a maximum size needed. (It ignores that there might be extra files in the directory, so we could also iterate the configured worlds running du on each if that's safer.) Then we could run df to make sure it has more space than we need. As part of the 'merge' that uses rsync to update the hddworld we could run df on the ramworld and complain if it is under a threshold.

Note that 'complain' in this context is something that baskit has never done before -- other than displaying messages at the console when you run the command. If we want additional notification we'll have to discuss/design it. Though I'd be tempted to get the first version pushed, pull-req'd and merged first.

[SteveMcGrath]

This may make a bit more sense.....

/opt/minecraft/persistance <--- Location of persistant copies of the worlds

At startup, new ramdisks for each world in this location are created and mounted into /env and all the data copied in. this saves the mess of all those symlinks.

Just trying to keep things clean. We don't need to cram everything into /env.

[IBCodin]

I don't have a personal stake in where the persistent copies end up, I just need to be able to find them to rsync and backup. I can even see the point in having it 'outside' the server directory.

agreen was arguing for 'permanent' tmpfs mount(s) so that the user logged in and running baskit didn't have to have sudo rights. We could insist on individual world mounts 'in-place' if the symlinks clutter the environment up.

I don't mind having baskit support creating the mounts if it has sudo rights and is configured to do so. In my 'latest dev' version it is In fact creating the mounts and unmounting them as appropriate. It just doesn't have any support to 'not' mount/umount at the moment.

[SteveMcGrath]

For the mounting/unmounting as non-root, this could easily be rectified by making a minor adjustment to the sudoers file to add the followling line:

%minecraft root=NOPASSWD: /bin/mount -t tmpfs none

Then adding all users that need to run these mounts to the minecraft group:

groupadd minecraft
useradd -G minecraft steve

[mr-bo-jangles]

I'm not sure if its possible to run python scripts as another user, but if at all possible that would be a better way around this. having a read + execute only /usr/bin/baskit that runs as user baskit. then you can give that user mount rights and not your end users.

[IBCodin]

Ok, I'm testing with the new implementation, but I ended up with the following sudoers line for the minecraft group:

%minecraft   ALL= NOPASSWD: /bin/mount -t tmpfs none /opt/minecraft/env/*, /bin/umount -t tmpfs /opt/minecraft/env/*

This gives the minecraft group passwordless mount/unmount of ramdisks in the environment directory
If your environment is somewhere else, change the /opt/minecraft/env parts.
Note that due to the way sudoers works, this line should be near the end of the file.

When editing the sudoers file, use visudo

My current implementation has no configuration for which worlds are ram disks...it looks in the persist directory and supports a ramdisk for each directory it finds there. Is this acceptable?

The current ramdisk config is:

enable_ramdisks = True
persist_folder = persist
automount_ramdisks = True
sudo_password_if_required = 

The sudo password is 'expected' if sudo is going to ask for a password.
With the sudoers entry above, if the user is in the minecraft group, sudo won't ask.
If automount is false, no attempt is made to mount or unmount the ramdisks and sudo is not used.
If automount is false, baskit verifies that the worlds are 'mount points' and that their total size
is at least as large as baskit would have made them.
If they are not mounted or not large enough, baskit refuses to start the server (and stops if you were running the cli).

[IBCodin]

I pushed a version that seems to run as a 'ramdisk' branch on my repo: IBCodin@78dac20

I think its pretty close (I did notice one test command I intended to remove). I'll do more testing on my system, I wouldn't mind either more testing or a second set of eyes running through the code.

[SteveMcGrath]

Ill look at it when I can get to a computer tomorrow afternoon.
On Nov 1, 2011 4:07 PM, "Robert Brinton" <
[email protected]>
wrote:

I pushed a version that seems to run as a 'ramdisk' branch on my repo:
IBCodin@78dac20

I think its pretty close (I did notice one test command I intended to
remove). I'll do more testing on my system, I wouldn't mind either more
testing or a second set of eyes running through the code.

Reply to this email directly or view it on GitHub:
#2 (comment)

[IBCodin]

I found a couple of issues in testing. I pushed another rev: IBCodin@e5f6895

[SteveMcGrath]

I pushed all the code into the master branch. As for the upcomming rewrite, it might be worth dropping into the IRC channel IBC so some of this can be hashed out if your willing to help.

[agreen]

thanks for your hard work. I'll load this on a test over the weekend and check it out. ;)

[SteveMcGrath]

@agreen so I'm assuming by the last of response everything went well?

[agreen]

My apology for the delay, I haven't had time to check. I have been
waiting for a RB of 1.0 to come out, which just happened within the
last couple of days. I will be able to test this then.

On Sun, Dec 18, 2011 at 3:42 AM, Steven McGrath
[email protected]
wrote:

@agreen so I'm assuming by the last of response everything went well?

---

Reply to this email directly or view it on GitHub:
#2 (comment)

[SteveMcGrath]

Closing this issue due to lack of activity.