helpdoc: ramdisk

an explanation of an uncommon gem

People are instantly wary the moment they hear RAMDISK--They think: volatile! Unexpected outages and the server is worthless and empty. Nothing could be farther from the truth!

Right out of the gates MineOS is a RAMDISK minecraft server. In fact, MineOS is Linux loaded into a RAMDISK itself! How does this equate to better performance? Read on.

a little background information

A RAMDISK is a filesystem mounted directly in the physical memory of your server. When MineOS boots from ISO (cd-rom/emulated cd-rom), the Linux kernel loads directly into memory. This is the setup for all servers. Linux kernel is loaded, Windows kernel, etc...are all loaded into memory so that low-level systems functions are always ready to be executed removing the chance of hard-drive spin-up delays or other I/O bottlenecks. If a kernel loaded in memory runs as fast as a machine is physically possible, how can we extend this performance to other areas? A ramdisk.


508.0K  bin
288.0K  etc
16.0K   home
5.6M    lib
32.0K   opt
8.0K    root
580.0K  sbin
0       sys
2.3M    usr
16.0K   var

This is the base filesystem of MineOS. As you can see, its about 9.3MB. What's more, with all other services running, we see the total memory foot print. (command: 'top')

Mem: 50112K used, 1520724K free, 0K shrd, 1112K buff, 13340K cached

This means the entire Operating system only uses 50MB of RAM. With servers having 2, 4, 8, 12GB of RAM, 50MB is nothing. And likewise, 150MB is nothing -- which is the size of a pretty size-able Minecraft world. If you can push your Minecraft world entirely into RAM, all chunkloads and chunk saves also occur at RAM-speed, orders of magnitude faster than any hard drive could achieve. Backups could also occur much faster, operating (read) on primary memory and writing to HD, instead of read AND writing from and on the HD. Everything in the server will run faster.

A little about volatility

But what about volatility? It is true, when a RAMDISK server gets taken down, whats stored in ram and not yet committed to disk is lost. But let's compare this to the EXISTING model that runs Minecraft.

Event "typical" Minecraft server ramdisked Minecraft server

Server unexpectedly crashes

(pure server)

Anything not committed to disk gets lost. Disk saves occur only when forced by an admin, on graceful server stop, or when chunks are unloaded (no player nearby)

Anything not committed to disk gets lost. Disk saves occur frequently at a user specified interval using crontabs.

Server unexpectedly crashes

(modded)

Using mods, such as the Save/Reload plugin, admins can force disk-commiting at user-specified intervals.

Save/Reload plugin is redundant, since crontabs already force 'save-all' to ramdisk, which is then rdiff-backup'ed to the hard drive.

Structures are heavily griefed

Griefed world is disk-commited an unknown interval, but if server is taken down 'gracefully', all griefs are committed to disk.

To backup, admins may only restore to most recent archived world, typically at an interval of 24 hours.

World is disk-committed at a regular interval (such as 15 minutes), making numerous restore points post-griefing.

However, with 15 minute interval restore points, you can restore your world 15, 30, 45, 60 minutes back, or any interval necessary to undo griefers.

Server is Columbus Griefed

Several players load into your world and start boating out in completely different directions, crippling the server's RAM and over-extending the hard drive through excessive read/writes as different areas of the map are generated and released from memory/committed to disk.

World chunkfiles are all loaded into RAM.

Newly generated chunks are saved from RAM to RAM.
Existing areas are loaded from RAM to RAM.

Though Columbus griefers will cause heavy bandwidth strain, they will not crash your server from over-queue of activity.

Server is doing backups

World is fully committed to disk and every chunk is processed, compressed and archived, regardless of if changed.

Processing of world is hard drive i/o bottlenecked.

(this is the typical Minecraft server backup behavior, as evidenced by the most popular backup scripts)

World is fully committed to ramdisk and every chunk is checksummed to determined if changed; only chunks that are found to be different are saved (incremental backup) to hard disk.

Processing occurs at RAM speed and compared to checksums saved to disk.

So there's a side-by-side comparison of using RAMDISK versus typical HD setups. As you can see, as "volatile" as RAMDISKs are, using MineOS properly not only increases your restore-precision, it also protects greater against griefing and is more reliably backed up.

What about solid-state drives?

Soid-state devices (SSDs) do not improve the reliability of your typical Minecraft Server!

Typically people think 'solid state' and assume that even during power-failure, all your world is safe. That is not the case. Not to mention solid state devices are extra costly by comparison. So why don't solid state drives help Minecraft?

Consider the typical Minecraft setup, commiting changes to hard-disk: until Minecraft commits chunk changes to disk, the chunks (and their changed state) are held in RAM. If your server goes down, those changes (still in RAM) are not even saved on your solid-state drive...they are lost from physical memory. A solid state drive will do nothing.

Should I use RAMDISK?

Well, I think RAMDISKs are downright brilliant and completely revolutionize the way Minecraft is hosted. On the other hand, the less familiar and comfortable you are with Linux, the less likely you are to recognize if your backups are scheduled properly, or if you restore them properly.

RAMDISKs have numerous advantages but come at a cost of more knowledge and willingness to dedicate time to proper setup. If you are unsure whether you are up to the task, or are unsure how to verify proper configuration, you may consider just the normal hard-disk setup and for its simplicity, even if it is not elegant.